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ABSTRACT 


This  thesis  describes  the  development  of  a  magnetic  tape 
library  system  (TLS)  for  the  Computer  Science  Department  of 
the  Naval  Postgraduate  School,  Monterey,  California.  The  TLS 
was  developed  using  the  Ingres  VM  UNIX  Version  2.1/15  VE.04 
database  management  system  on  the  4.2  BSD  UNIX  operating  sys¬ 
tem.  The  thesis  includes  a  requirements  analysis  and  design, 
and  a  description  of  implementation. 
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INTRODUCTION 


The  Computer  Science  Department  maintains  a  variety  of 
magnetic  tapes  for  their  instruction  laboratory.  The  current 
combination  manual /computerized  library  system  is  ineffi¬ 
cient.  The  department  wants  a  computer-based  system  by  which 
librarians  may  add,  locate,  update,  and  provide  reports 
regarding  tapes  in  the  library.  There  are  currently  six  li¬ 
brarians  who  are  staff  members  of  the  department.  In  addi¬ 
tion  to  their  librarian  duties,  they  are  responsible  for  some 
form  of  maintenance  of  the  department's  two  VAX  11/780  and 
one  VAX  11/750  computers.  The  maintenance  administration  is 
performed  with  the  VAX  11/780/UNIX  operating  system.  The 
department  wants  a  tape  library  to  be  developed  using  the 
Ingres  (VM  UNIX  Version  2.1/15VE.04)  database  management  sys¬ 
tem  (DBMS),  the  4.2  BSD  UNIX  operating  system. 

The  database  development  process  will  be  used  to  build  a 
tape  library  system  (TLS) .  It  will  be  developed  in  four 
stages  —  requirements  specification,  evaluation,  design,  and 
implementation . 

A.  REQUIREMENTS  SPECIFICATION 

The  management  of  the  Computer  Science  Department  has 
already  defined  the  need,  and  estimated  the  cost/benefit  of 
the  project.  They  approved  its  continuation  v/r.er,  r-- 


The  current  tape  library  is  a  combination  of  a  casual 
computer  listing  of  approximately  600  tapes,  and  opened 
cabinets  in  which  tapes  are  segregated  by  type. 

The  library  system  must  facilitate  use  by  the  six  li¬ 
brarians.  The  need  to  store  and  catalog  tapes  dependably 
is  critical.  It  must  ensure  the  security  of  the  data  and 
tapes.  Guidance  for  logging  data  must  be  well  defined  and 
interactively  p.  , mpted  to  ensure  input  of  all  necessary 
information . 

Development  of  the  library  by  a  thesis  student  for  use  on 
the  VAX  11/780/UNIX  operating  system  and  Ingres  database  will 
keep  costs  to  a  minimum.  No  new  hardware,  software,  or  per¬ 
sonnel  purchases  will  be  required.  Because  all  the  librar¬ 
ians  have  extensive  experience  with  the  system,  minimum 
training  will  be  required.  This  thesis  describes  development 
of  the  TLS. 

Detailed  user  requirements  will  be  determined  by  exten¬ 
sive  interviews  with  the  users.  The  department  has  assigned 
a  user  team  leader.  The  current  system  and  desired  changes 
will  be  documented  in  Chapter  1 1  by  a  narrative  and  data  flow- 
diagrams.  The  proposed  system  will  be  documented  by  data 
flow  diagrams,  process  mini-specifications,  data  items,  and  a 
specification  data  dictionary.  The  new  system  will  be  re¬ 
viewed  and  approved  by  the  users  before  the  evaluation  stage 
commences . 


B.  EVALUATION 

The  evaluation  stage  will  be  limited  because  the  depart¬ 
ment  has  already  delineated  the  system  hardware,  operating 
system,  application  language,  data  technology,  and  people. 
The  database  design,  application  program,  and  procedural 
alternatives  will  be  developed  for  evaluation  and  selection 
by  the  user.  A  project  plan,  outlining  major  dev.  lopment 
tasks,  will  be  documented  for  use  by  the  developer  and  user 
in  following  project  development. 

C.  DESIGN 

The  design  stage  will  include  definition  of  the  database 
structure  application  program,  security  and  control,  and 
functions  of  the  database  administrator. 

In  Chapter  III,  the  database  structure  will  first  be 
defined  logically,  independent  of  the  requirements  of  Ingres, 
according  to  the  rationale  of  the  data  record  relationships 
and  fields.  These  relationships  will  be  illustrated  by  data 
structure  diagrams  (Bachman  diagrams).  They  will  be  defined 
in  a  logical  schema. 

In  Chapter  IV,  the  logical  structure  will  be  mapped  to 
t;ie  physical  structure  of  Ingres.  The  relations,  data, 
formats,  and  the  functions  and  interfaces  of  the  modules  will 
be  included  in  the  design  data  dictionary.  The  application 
program  will  be  designed  in  parallel  with  the  database 
iesign.  c'^curity  and  control  procedures  will  be  l.^sigr.ed 


into  the  application  program  to  ensure  that  only  authorized 
users  may  access  the  library. 

A  tutorial  will  be  developed  in  parallel  with  the  appli¬ 
cation  program  and  will  be  included  as  Appendix  G.  It  will 
include  operating  procedures,  security  specifications,  and 
the  database  administrator's  responsibilities  for  mainte¬ 
nance  of  the  library. 

D.  IMPLEMENTATION 

The  application  will  be  coded  in  the  Ingres  DBMS  lan¬ 
guage.  A  small  representative  database  will "be  loaded  into 
the  database.  All  modules  will  be  tested.  Users  will  be 
trained.  Full  loading  of  the  600  tapes  will  be  accomplished 
by  the  staff  librarians.  Instructions  for  implementation  are 
provided  in  Appendix  F.  Final  conclusions  and  recommenda¬ 
tions  will  be  included  in  Chapter  V. 
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II.  REQUIREMENTS  ANALYSIS 


A.  NARRATIVE 

1 .  Background 

The  Computer  Science  Department's  current  tape  li¬ 
brary  is  a  combination  of  a  casual  computer  listing  of  600 
tapes,  and  opened  cabinets  in  which  tapes  are  segregated  by 
type.  Tape  labels  contain  as  much  information  as  possible  in 
case  the  information  in  the  library  listing  is  inaccurate, 
incomplete,  or  nonexistent.  The  information  in  the  listing 
is  not  standardized.  It  consists  of  whatever  one  of  eight 
librarians  considered  necessary  for  identification  or  re¬ 
trieval  when  (s)he  entered  the  tape  into  the  library.  Fre¬ 
quently  customers  help  themselves  to  shelved  tapes,  and  new 
boxed  tapes  sometimes  disappear.  Few  staff  and  student 
personnel  request  the  library  to  store  their  tapes.  The 
department  would  like  to  provide  secure,  dependable  library 
services . 

Compounding  the  problem,  the  computer  facilities  are 
rapidly  expanding.  Dependence  on  the  facilities  is  increas¬ 
ing  and  people  are  requesting  better  library  services.  Con¬ 
currently,  requests  for  backup  tapes  are  increasing  as  is 
the  length  of  time  between  when  a  backup  is  created  and  re¬ 
trieved.  More  tapes  are  getting  lost.  The  need  to  store  and 
rata  leg  tapes  dependably  is  critical. 


2.  Users 


Approximately  six  to  seven  staff  personnel,  all 


extensively  familiar  with  computers,  perform  librarian  duties 


and  will  have  access  to  the  library  and  tapes.  Because  of 


the  large  number  of  librarians,  guidance  for  logging  data 


must  be  well-defined  and  interactively  prompted  to  ensure 


that  all  necessary  information  is  input. 


3 .  Storage 


The  tapes  will  be  stored  in  locked  cabinets  with  sep¬ 


arate  slots  for  each  tape.  The  staff  would  prefer  not  to 


physically  separate  the  tapes  by  category  and  not  to  have 


descriptive  information  on  the  tape  labels.  This  will  help 


to  prevent  customers  from  helping  themselves  to  tapes  they 


need  if  cabinets  are  inadvertently  left  unlocked.  Only  the 


librarians  should  have  access  to  the  tapes. 


4 .  Tape  Entry 


Tapes  are  received  into  the  library  in  three  ways: 


1)  boxes  of  new  tapes;  2)  tapes  from  vendors,  and  3)  written 


tapes  requested  for  safekeeping  by  private  owners.  To  pre¬ 


vent  pilferage,  it  is  desired  that  new  tapes  be  identified 


and  placed  into  the  library  immediately.  Physical  informa¬ 


tion  about  these  blank  tapes  must  be  included.  They  will 


eventually  be  used  to  write  backups.  Vendor  tapes  are  iden¬ 


tified  and  catalogued  as  soon  as  possible.  They  are  never 


retired  for  use  as  backups.  Tapes  input  for  safekeeping  must 


be  identified.  If  abandoned  bv  the  user,  thev  mav  be  used 


uStS 


for  backups.  Essentially,  the  moment  a  tape  is  received  by 
the  library,  it  should  be  identified  with  as  little  informa¬ 
tion  as  possible  on  the  label.  It  should  be  labelled  with  an 
identification  number  only,  which  can  be  used  to  locate 
assigned  space  in  the  cabinet  and  its  descriptive  information 
in  the  library. 

5 .  Backups 

It  is  the  function  of  the  tape  librarians  to  perform 
backups.  They  do  routine  system  backups,  and  "individual" 
backups  by  special  request  for  staff,  faculty,  or  student 
personnel.  For  individual  requests,  the  owner's  tapes  main¬ 
tained  by  the  library  may  be  reviewed  to  determine  if  there 
is  sufficient  space  available  on  one  to  read  the  disk  files 
requested  to  the  partially  used  tape.  To  perform  an  individ¬ 
ual  backup  when  an  appropriate,  partially  used  tape  cannot  be 
found,  or  to  perform  any  other  backup,  the  librarian  must 
first  find  a  "scratch"  tape,  either  new  or  previously  used. 
It  must  be  of  sufficient  condition,  density  capacity,  and 
length  to  accommodate  the  backup.  After  the  information  on 
backup  tapes  is  retired,  the  librarian  makes  the  tape  avail¬ 
able  for  rewrite. 

a.  Routine  Backup 

Daily  disk  backups  are  written  to  tape  each  week. 
Weekly,  disks  are  written  to  tapes.  Full  backups  of  the 
system  are  written  to  tape  monthly.  Information  kept  in 


library  must  enable  the  librarian  to  access  the  tapes  and 
write  them  back  to  disk.  They  must  be  identified  by  the 
date  and  time  of  backup,  the  system,  utility,  software  used 
to  generate  the  tape,  and  path  information  such  as  partition 
or  disk,  or  source.  Each  daily  backup  is  1-2  tapes  long, 
weeklys  require  2-3  tapes,  and  monthly's  4-6  tapes.  The 
library  will  save  dailies  for  one  month,  weeklys  for  two 
months,  and  monthlys  for  six  months. 

When  a  Computer  Science  class  graduates  (14-17 
students)  the  librarian  creates  a  tape  backup  of  graduated 
student  disk  files  for  each  system.  Each  is  1-2  tapes  long. 
Again,  the  librarian  must  find  a  tape  of  the  appropriate 
length,  condition,  and  density  capacity.  After  writing  the 
tape,  the  librarian  must  catalogue  information  which  will 
enable  retrieval  of  a  student's  files  to  write  them  to  disk 
or  another  tape.  This  information  must  include  date,  student 
name,  the  .specific  files,  the  operating  system  hardware  and 
utility  used  to  generate,  and  device.  The  tapes  will  be  kept 
for  two  years . 

DATA  RETENTION 

DAILY  BACKUPS  1  MONTH 

WEEKLY  BACKUPS  2  MONTHS 

MONTHLY  BACKUPS  3  MONTHS 

GRADUATION  BACKUPS  2  YEARS 

INDIVIDUAL  BACKUPS  2  YEARS 

VENDOR  BACKUPS  5  YEARS 


b.  Nonroutine  Backups  (Individual  Tapes) 

Staff,  faculty,  or  students  frequently  request 
that  a  disk  file  be  written  to  tape.  The  librarian  first 
checks  to  see  if  the  individual  currently  owns  a  tape  in  the 
library  of  the  same  system,  copied  with  the  same  utility  and 
device  as  required  to  access  the  file(s),  that  has  a  suffi¬ 
cient  unused  portion  to  write  the  file(s)  requested.  If  an 
appropriate  tape  is  found  and  used,  the  addition  of  the  new 
file(s)  must  be  recorded  into  the  library.  If  there  are 
none,  the  librarian  must  look  for  an  adequate  scratch  tape. 
If  a  new  tape  was  used  because  the  owner  had  no  previous 
tape(s)  on  file,  the  librarian  identifies  it  as  a  new  set 
with  a  new  sequential  order.  A  set  of  individual  tapes  can 
include  up  to  three  volumes.  After  copying  the  tape,  the 
librarian  catalogs  the  information  necessary  to  find  which 
tape  the  new  file  is  on  and  how  to  write  it  to  disk  or 
another  tape. 

6 .  Administrative 

a.  Condition  of  Tapes 

The  librarian  is  responsible  for  monitoring  the 
condition  of  the  tapes  and  to  recopy  or  throw  out  tapes  as 
required.  Condition  is  determined  in  one  of  two  ways:  errors 
and  bit  age. 

( 1 )  Errors 

Errors  are  unreadable  bit  spaces  on  the  tape 
and  are  ccmmunicated  to  the  librarian  by  the  utilitv  each 


time  the  tape  is  read  or  written.  Ten  to  twelve  errors 
(after  head  cleaning)  is  considered  maximum  life.  The 
librarian  must  catalogue  this  information  each  time  the 
physical  tape  is  read  or  written.  Physical  tapes  exceeding 
their  maximum  cycle  or  error  life  are  permanently  deleted 
from  the  library  and  thrown  away. 

(2)  Bit  Age 

Bit  age  has  to  do  with  the  information 
written  on  the  tape  and  applies  only  to  active  tapes  (vendor 
or  backups) .  It  is  the  age  of  the  oldest  bit  on  the  tape. 
Bits  deteriorate  after  five  years  so  the  tape  information 
must  be  copied  to  another  tape.  The  physical  tape,  however, 
may  be  reused.  Checks  for  bit  age  must  be  done  on  all  tapes 
on  a  periodic  basis. 

b.  Retirement  of  Tapes 

The  librarian  requires  a  flexible  means  of  con¬ 
trolling  the  length  of  time  all  active  tapes  are  retained  by 
the  library,  other  than  by  condition.  The  reasons  could  vary 
per  type  of  active  tape.  When  the  retirement  date  occurs,  a 
disposition  decision  will  be  made. 

c.  Lending  of  Tapes 

Vendor,  scratch,  and  individual  tapes  may  be 
loaned.  The  library  must  maintain  information  regarding 


7 .  Deleting  Tapes 

Backup  tapes  may  be  retired  to  scratch  tapes,  or  any 
tape  may  be  thrown  away.  For  retiring  backups,  the  librarian 
must  provide  a  means  to  delete  backup  information  but  retain 
the  physical  tape  information.  It  must  allow  deletion  of  all 
tape  information  and  reflect  the  availability  of  a  vacant 
labelled  slot  in  the  cabinet  when  a  tape  is  thrown  away. 


B.  DATA  FLOW  DIAGRAMS  (DFD) 

1 .  Current  Library 

An  overview  of  the  current  TLS  described  in  the 
narrative  is  illustrated  by  a  DFD  (Figure  1).  Minispecifi¬ 
cations  and  file  descriptions  follow  the  DFD. 

2 .  Proposed  Library 

A  general  overview  of  proposed  library  procedures  is 
reviewed  in  DFD(O)  (Figure  2).  All  procedures  are  to  be  per¬ 
formed  by  a  librarian.  Subsequent  DFDs  (Figures  3-10)  are 
more  detailed.  The  procedures  are  numbered  1-9.  The  pro¬ 
cedures  and  data  input  and  output  for  each  procedure  varies 
according  to  the  function  the  librarian  performs.  A  DFD  is 
written  for  each  function  to  illustrate  the  specific  proce¬ 
dures  and  data  inputs  and  outputs  required.  Functions  are 
assigned  letters  A-H.  Mini-specifications  of  the  procedures 
and  a  specification  data  dictionary  follow  each  DFD.  The 
procedure  numbers  of  the  functional  DFDs  match  the  procedure 
to  the  definition  provided  in  the  overview  DFD(C)  and  -re 


preceded  by  the  appropriate  function  letter.  For  example; 
"A. 2"  should  be  read  -  Function  A,  Procedure  2. 

For  some  functions,  a  procedure  is  broken  down  into 
sub-procedures.  Sub-procedures  retain  the  function  and  pro¬ 
cedure  number,  followed  by  a  decimal  number  (i.e.,  A. 2.1 
should  read  -  Function  A,  Procedure  2,  Sub-procedure  1). 

Cabinets  and  the  database  will  be  the  only  files  used 
to  store  library  objects  and  information.  Cabinets  will  con¬ 
sist  of  labelled  slots,  consecutively  numbered  left  to  right, 
top  to  bottom.  The  range  of  the  numbering  system  will  be 
expanded  as  tapes  are  added.  Cabinets  will  be  known  by  the 
range  of  numbers  assigned.  For  example,  a  cabinet  may  be 
known  as  100-300. 

The  library  data  will  be  the  only  source  of  infor¬ 
mation  regarding  labelled  cabinet  spaces,  the  physical  con¬ 
dition  of  tapes  assigned,  and  the  data  preserved  on  a  tive 
tapes  (vendor  tapes  and  backup  tapes).  A  backup  tape  is  a 
tape  with  information  which  the  library  safeguards. 
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MINI-SPECIFICATION:  THE  OLD  SYSTEM  LIBRARY  -  OVERVIEW 


1.  Edit  Request  The  librarian  or  requestor  edits  the  re¬ 

quest  at  this  time  to  determine  what 
action  to  take. 

2.  Query  for  The  requestor  or  librarian  searches  for 

Tape(s)  the  tapes  which  will  satisfy  the  request. 

3.  Select  The  librarian  or  requestor  selects  the 

Appropriate  equipment,  if  required,  to  satisfy  the 

Equipment  request. 

4.  Get  Tape{s)  The  librarian  gets  appropriate  tape{s). 

5.  Perform  The  librarian  or  requestor  performs  the 

Read/Write  read/write,  if  required. 

6.  Return  Tape(s)  The  librarian  returns  the  bape(s)  to  the 

cabinet;  the  requestor  might  or  might 
not . 

7.  Update  The  librarian  updates  the  database;  the 

Database  requestor  does  not. 


FILES 

Four  objects  serve  as  files  in  the  current  library. 

CABINETS  Cabinets  have  slots  which  hold  the  tapes.  These 
slots  are  not  numbered.  The  tapes  which  are 
contained  in  them  have  labels  with  numbers  and 
tape  information.  An  attempt  is  made  to  place 
reels  of  similar  systems  and  tapes  in  specific 
sections  of  the  cabinets.  The  cabinets  are 
opened  and  easily  accessible  to  anyone  at  NPS, 

DATABASE  A  vaguely  defined  computerized  file  of  tape  num¬ 
bers  with  information  for  the  librarian  regarding 
the  tape.  Information  required  to  perform  subse¬ 
quent  functions  is  frequently  omitted.  This  data 
is  also  written  onto  the  tape  label. 

NEW  BOXED  New  tapes  received  are  left  in  boxes  near  the 

cabinets.  The  physical  parameters  of  the  tapes 
appears  on  the  labels.  The  box  is  accessible  to 
anyone . 


SINK 


Tapes  sometimes  disappear. 


LIBRARY  DATA 


Function:  General  Procedures  of  the  Proposed  Library 

Mini-specifications  0 


The  following  procedures  are  required  by  most  of  the 
functions  the  librarian  performs.  The  combination  of  pro¬ 
cedures  and  the  data  input  and  output  for  each  procedure  will 
vary  according  to  the  function  requested. 

1.  Edit  An  event/discussion  with  a  requestor 

to  determine  the  function  required. 

For  example: 

Add  empty  cabinet  slots 
Add  scratch  tapes 
Add  vendor  tapes 
Write  disks  to  tape: 

To  partially  used  individual  tape 
To  backup  tape 
To  scratch  tape 
Read  active  tape  to  disk 
Loan  Tape 

Receive  returned  loaned  tape 
Delete  tapes 

2.  Query  TLS  Data  Provide  criteria  upon  which  the 

information  requested  is  retrieved. 

3.  Select  IDs  Select  the  id  numbers  which  are 

required  to  perform  the  function. 

4.  Label  Make  labels  for,  and  label  objects  for 

each  id  number  selected. 

5.  Get  Tape(s)  Go  to  the  cabinet  slot  labelled  with 

the  selected  id  number  and  withdraw 
the  tape ( s )  . 

6.  Perform  Perform  write  disk  to  tape  or  read 

Read/Write  tape  to  disk,  as  appropriate. 

7.  Replace  Tape(s)  Replace  tape(s)  to  the  cabinet  slot 

which  matches  the  identification 
number  on  the  tape  label. 

8.  Update  TLS  Data  Add  to,  or  update  TLS  data  with  new 

information  regarding  the  cperat'lc r. 
performed . 


Function:  Add  new  scratch  Tapes  to  Library 

Mini-specifications  A 


1. 

Edi  t : 

Log  Scratch 

Request  to  log  scratch.  Log  new  un¬ 
labelled  tape(s)  upon  arrival.  Read 
physical  parameters  from  manufacrer's 
label . 

2. 

Query 

Empty  Slots 

Query  library  data  for  lowest  empty  id. 

3.1 

Calculate 

New  id 

If  no  empty  slots  are  available, 
calculate  new  id  number 

3.2 

Assign  id ( s ) 

Select  the  id(s)  to  assign  to  the 
scratch  tape 

1 — 1 

• 

Labe  1  Tape ( s ) 

Label  the  tape(s)  with  the  "assigned  sic 
id  number. 

4.2 

Label  Cabinet 

Label  the  cabinet  space  with  the  new  id 

8. 

Add  Scratch 

If  id  was  of  an  empty  slot,  update  tape 
physical  parameters  to  the  id  record. 

If  new  id,  add  id  and  tape  parameters. 

Data  Items  A 


Physical 

Type 

Empty  Slot  id 
None 

New  id  Selected 
Labelled  Tape 
Labe  1 


=  length  +  density 
=  (type  =  empty) 

=  id  +  (type  =  empty) 

=  no  empty  slots 
=  max  id  +  1 
=  Tape  +  id 

=  a  label  with  an  id  number  to  be  put 
on  the  cabinet  space 

=  id  +  (Type  =  scratch)  +  length 
+  density 
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Scratch  Record 


Function:  Add  Vendor  Tapes 


Mini-specification  B 


1.  Edit;  Vendor 

2.  Query  Empty  Slots 

3.1  Assign  id(s) 

3.2  Calculate  New 
id  Numbers 

4.1  Label  Tape(s) 

4.2  Label  Cabinet 
Space (s) 

8.  Add  Vendor  Tape(s) 
to  TLS 


The  tape  is  software  from  a 
vendor  for  the  library  to  log  and 
maintain 

Query  the  library  data  for  lowest 
empty  id 

Assign  the  id  to  the  vendor  tape 

If  no  empty  slots  are  available, 
calculate  the  new  id  number 

Label  the  tape(s)  with  the 
assigned  slot  id  number 

Label  the  cabinet  space  with  the 
new  id 

Add  software  tape(s)  record  to 
the  library  data 


Data  Items  B 

Physical 

Software 


Type 
Slot  id 
None 
New  id 


bpi 

(type  =  vendor)  +  system  + 
utility  +  label  +  date 
received  +  retirement  date  + 
owner  +  contact  phone  +  soft¬ 
ware  +  vendor  +  description  + 
sequence 

Type  empty 

id  +  (type  =  empty) 

No  empty  slots 

max  id  +  1 


Software  Tape  Record 


id  +  (type  =  vendor  )  +  bpi 

+  software 


•Tf 

r 


Function;  Write  Individual's  Disk  to  Tape 
Mini-specification  C 


p  ~  1 

5. 

6. 

7. 

8  . 

1.  Edit:  Write 
Disk  to  Tape 


1.1  Determine  File 
Location  and 
Length  of  Files 

1.2  Select  Equipment 


2 .  Query  Owner ' s 
Tape ( s ) 


3.  Select  Tape 


D.1.2  Go  to 

Procedure  D.1.2 


Get  Tape 
Perform  Backup 
Return  Tape 
Update  TLS 


If  type  =  individual  staff, 
faculty,  or  student  backup. 
If  not  go  to  DFD(E). 

By  discussion  or  may  require 
searching  files. 


The  computer  and  operating  sys¬ 
tem  combination  determines  the 
device.  The  device  determines 
the  density  which  can  be  used. 

Query  the  library  data  for  a 
listing  of  the  owner's  backup 
tapes  which  may  be  used  to  copy 
the  files  requested. 

Select  a  backup  tape  which  may  be 
used  to  write  the  requested  file. 

If  none  of  the  owner's  tapes  are 
appropriate  to  use,  go  to  Proce¬ 
dure  1.2  of  DFD(D)  and  resume 
looking  for  a  scratch  tape  to 
perform  the  write. 


Write  disk  files  to  the  tape. 


Add  the  record  of  the  new  files 
to  the  library  data.  If  the 
utility  reads  error  information 
different  than  that  recorded  for 
the  tape,  update. 


Data  Items  C 

Type 

Owner 

Approximate  File 
Path 

Type 

Density 

Tape  Requirements 

Owner  Tape  Listing 

File  Path 

File  Lengths 

Utility 

None 

Errors 


=  individual,  staff,  faculty,  or 
student  backup 

=  the  owner  of  the  individual 
backup  tape 

*  (some  or  all)  (system  +  owner 
+  partition/disk) 

=  individual,  staff,  faculty,  or 
student 

=  bits  per  inch  (bpi) 

=  (some  or  all)  (type  =  indivi¬ 
dual)  +  owner  +  system  + 
density 

*  id  +  length  +  density  +  loaned 
+  system  +  utility  +  label, 
percent  used  +  retirement  date 

*  Partition/disk  +  saveset/ 
source 

»  Approximate  length  of  magnetic 
tape  needed  to  copy  the  files 

*  Utility 

=  No  tapes  meet  the  requirements 
for  the  backup 

=  Error,  date  of  errors 

=  id  +  errors  +  date  of  errors 
+  partition/disk  +  saveset/ 
source 


Record  of  Backup 


LIBRARY  DATA 


Function:  Write  Disk  to  Scratch  Tape 

Mini-specification  D 


1.  Edit:  Write  Disk 
to  Scratch 

1.1  Determine 
File  Location 
and  Length 

1.2  Select  Equipment 
Required 

2.  Query  Scratch 

3.  Select  Scratch 
Tape ( s ) 

5.  Get  Tape(s) 

6.  Perform  Backup 

7.  Return  Tape(s) 

8.  Add  to  TLS 

Data  Items  D 

Function:  Write  D 

Approximate  File  = 

Path 

Type  Backup  = 

hN  Type  Tape 


If  type  =  daily,  weekly,  monthly, 
or  graduation  backup 

By  discussion  or  may  require 
searching  files 


The  computer  and  operating  system 
combination  determines  the 
device.  The  device  determines 
the  density  which  can  be  used. 

The  utility  is  determined  by  the 
system  and  the  density 

Query  the  database  for  scratch 
tapes  which  have  the  physical 
parameters  required  by  the  edit 
procedure 

Select  ids  from  the  listing  of 
scratch  tape(s)  provided  by  the 
database 

Retrieve  tape(s)  with  the  id(s) 
selected 

Write  disk  files  requested  to 
the  tape 


Enter  the  information  regarding 
the  backup  to  the  library  data 


sk  to  Scratch 

(some  or  all)  (system  +  part/disk  + 
saveset/ source) 

daily,  weekly,  monthly,  graduation, 
or  individual  backup 

Type  =  scratch 


Density 

Tape  Requirements 


bits  per  inch  (bpi) 


Scratch  Tape  List 

File  Length 

File  Path 
Equipment 
Errors 
Equipment 
Record  of  Backup 
Daily 


Weekly/ Monthly 


Graduation 


Individual 


(Type  =  scratch)  +  length  +  density  + 
errors  +  date  of  errors 

id  +  length  +  density  +  errors  +  date 
of  errors  +  loan 

Approximate  length  of  magnetic  tape 
needed  to  copy  the  file(s) 

Partition/disk  +  saveset/source 

System  +  utility  +  density 

Error  +  date  of  errors 

System  +  utility  +  density 

Various  according  to  type: 

id(s)  +  type  +  errors  +  date  of 
errors  +  label  +  sequence  +  date 
created  +  retirement  date  +  system  + 
utility  +  description  +  partition/ 
disk  +  saveset ( s ) /source (s ) 

i'd(s)  +  type  +  errors  +  date  of 
errors  +  label  +  sequence  +  date 
created  +  retirement  date  +  system  + 
utility  +  description  +  partition/ 
disk  +  saveset/source 

id(s)  +  type  +  errors  +  date  of 
errors  +  label  +  sequence  +  date  of 
graduation  +  retirement  date  +  system 
+  utility  +  description  +  partition/ 
disk(s)  +  saveset (s) /source (s) 

id(s)  +  type  +  errors  +  date  of 
errors  +  label  +  sequence  +  percent 
used  +  date  created  +  retirement  date 
+  system  +  utility  +  description  + 
owner  +  advisor  +  contact  phone  + 
partition/disk (s)  +  saveset(s)/ 
source ( s ) 
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Function;  Read  Tape  to  Disk 
Mini-specification  E 


1. 

Edit;  Read  Tape 
to  Disk 

2. 

Query  Backup/ 
Vendor  Tapes 

3. 

Select  Backup 
Tape (s) 

5. 

Get  Tape(s) 

6.1 

Select  Equipment 

6.2 

Perform  Read 

7. 

Return  Tape(s) 

8. 

Update  TLS 

Data  Items  E 


Requestor  would  like  a  vendor  or 
backup  tape  read  to  disk. 

Query  the  library  with  as  much 
information  as  the  requestor  can 
provide  concerning  the  tape. 

Select  from  the  database  listing 
the  exact  tapes  needed  to  perform 
the  read. 

Retrieve  tape(s)  with  the  id 
numbers  selected. 

Select  the  equipment  defined  in 
the  database. 


If  the  physical  information 
provided  by  the  utility  regarding 
the  tape  is  different  than  that 
in  the  library  data,  update. 


General  Backup 
Description 


(Some  or  all)  type  +  date  created 
+  system  +  name  of  owner  +  software 
+  vendor 


Approximate  Tape 


(Some  or  all)  Varies  according  to 
type ; 


Vendor 


(Type  =  vendor)  +  system  +  software 
vendor 


Periodic  =  (Type  =  daily,  weekly,  monthly,  or 

graduation)  +  date  +  system  + 
partition/disk 


Individual 


(Type  =  staff,  faculty,  student) 
+  s vs  tern  +  owner 


Tape  List 


Varies  according  to  type  backup: 


Vendor 


Periodic 

Individual 


Equipment 
File  Path 
Errors 

Error  Record 


=  id(s)  +  density  +  loan  +  errors  + 

label (s)  +  sequence  +  date  received  + 
system  +  utility  +  description  + 
owner  +  contact  phone  +  software  + 
vendor  +  partition/disk  +  saveset(s)/ 
source (s) 

=  id(s)  +  (type  =  daily,  weekly, 

monthly,  or  graduation  )  +  errors  + 
label  +  sequence  +  date  +  system  + 
utility  +  description  +  partition/ 
disk  +  saveset (s) /source (s) 

=  id{s)  +  (type  =  staff,  faculty, 

student)  +  density  +  loan,  errors  + 
label (s)  +  sequence  +  percent  used  + 
date  +  system  +  utility  +  owner  + 
advisor  (if  student)  +  Contact  phone 
+  description  +  partition ( s ) /di sk ( s ) 

+  saveset (s) /source  (s) 

=  system  +  utility  +  density 

=  partition/disk  +  saveset/source 

=  errors  +  date  of  errors 

=  id  +  error  update 


Function;  Loan  Tapes 
Mini-specification  F 


If  requested  by  anyone  but  a 
librarian  to  remove  a  tape(s) 
from  the  library.  Type  tape  must 
be  vendor,  individual,  staff, 
student,  faculty.  Permission 
from  the  owner  should  be  obtained 
before  lending. 

Query  database  for  id  of  tape(s) 
requested . 

Select  ids  of  requested  tape(s) 
from  database  listing. 

Retrieve  tape(s)  with  the  id 
numbers  selected. 

8.  Add  (Loan  Update  the  library  to  contain 

Information)  information  regarding  the  loan, 

to  TLS 


Data  Items  F 

General  Backup  =  (Some  or  all)  type  +  date  created 

Description  +  system  +  name  of  owner  +  software 

+  vendor 

(Some  or  all)  Varies  according  to 
type : 

(Type  =  vendor)  +  system  +  software 
+  vendor 

Periodic  =  (Type  =  daily,  weekly,  monthly,  or 

graduation)  +  date  +  system  + 
partition/disk 

Individual  =  (Type  =  staff,  faculty,  student) 

+  system  +  owner 

Tape  List  =  Varies  according  to  type  backup: 

Vendor  =  id(s)  +  density  lean 

label  (.3)  +  sequence  ::a 

system  utility  +  descr 


Approximate  Key 

Vendor 


1.  Edit:  Request  to 
Borrow  Tape(s) 


2.  Query  for 
Tape(s)  Requested 

3 .  Select  Tape ( s ) 
to  Lend 

5 .  Get  Tape  ( s ) 


■•.  V  . 


Periodic 


Individual 


Loan  Agreement 


+  contact  phone  +  software  +  vendor  + 
partition/disk  +  saveset  (s) /source  (s) 

id(s)  +  (type  =  daily,  weekly, 
monthly,  or  graduation)  +  errors  + 
label (s)  +  sequence  +  date  +  system  + 
utility  +  description  +  partition/di s 
+  saveset (s) / source ( s ) 

id(s)  +  (type  =  staff,  faculty, 
studen-^l  +  density  +  loan,  errors  + 
label (sy  +  sequence  +  percent  used  + 
date  +  system  +  utility  +  owner  + 
advisor  (if  student)  +  contact  phone 
description  +  partitiion ( s ) /disk ( s )  + 
saveset (s) /source (s) 

loan  +  date  loaned  +  estimated  date  o 
return  +  loanee  +  loanee's  contact 
phone 


Record  of  Loan 


id  +  loan  agreement 


LIBRARY  DATA 


Function;  Returned  Loaned  Tapes 
Mini-specification  G 


tv 


1.  Edit;  Returning 
Borrowed  Tape(s) 


2 .  Query  Loaned 
Tape  (s) 

3.  Verify  Correct 
Tape (s) 


5.  Replace  Tape(s) 
8.  Delete  Loan 


Data  Items  G 


Tape 

Loaned  Tape  List 
Updated  Record (s) 


The  requestor  (loanee)  returns 
tape(s)  borrowed  from  the 
library. 

Query  the  library  to  find  which 
tapes  are  held  by  the  loanee. 

Verify  the  returned  tape(s) 
belonging  to  the  library,  that 
all  are  present,  etc. 


Delete  the  record  (s)_  of  the  loan 
from  the  library  data. 


=  tape  +  id 

=  loanee  +  id(s) 

=  id  +  (loan  =  no)  +  (delete 
record  of  loan) 


Function:  Delete  Tapes  (erase  backup  or  trash 

physical  tape) 

Mini-specification  H 


1.  Edit:  Request  to  Valid  if: 

Delete  Backup 

or  Tape(s)  Any  type  tape  is  first  copied  to 

another  tape  and  then  logged  into 
the  library. 

Daily,  weekly,  monthly,  or 
graduation  backup  =  retirement 
date  <=  current  date. 


Vendor  or  individual  staff, 
faculty,  student  =  owner  = 
requestor. 


2. 

Query  for  Tape(s) 

Query  library  for  a  listing  of 
tape(s)  which  satisfy  the 
requestors  description  of  the 
tape (s) . 

3. 

Select  Tape(s) 

Select  the  id(s)  of  the  tape(s) 
desired  for  deletion. 

4. 

Get  Tape(s) 

Included  only  if  trashing 
tape  (s)  . 

8. 

Delete  Records 

Delete  records  to  reflect  the 
erasure  of  backup  or  the  trashing 
of  a  physical  tape 

Data  Items  H 

General  Backup  = 

Description 

(Some  or  all)  type  +  date  created 
system  +  name  of  owner  +  software  + 
vendor 

Approximate  Key  = 

(Some  or  all)  Varies  according  to 
type : 

Vendor  = 

(Type  =  vendor)  +  system  +  software 

+  vendor 


Periodic 


(Type  =  daily,  weekly,  monthly,  or 
graduation)  +  date  +  system  + 
partition/ disk 


Individual 

Expired  Retirement 
Date 

Tape  List 

Vendor 


Periodic 


Individual 


ids 

New  Record: 

If  to  Delete 
Tape  Data 

If  to  Trash 
Tape 


(Type  =  staff,  faculty,  student)  + 
system  +  owner 

Requirement  date  <=  today's  date 


Varies  according  to  type  backup: 

id(s)  +  density  +  loan  +  errors  + 
label (s)  +  sequence  +  date  received 
+  system  +  utility  +  description  + 
owner  +  contact  phone  +  software  + 
vendor  +  partitioin (s ) /disk ( s )  + 
saveset (s ) /source ( s ) 

id(s)  +  (type  =  daily,  weekly, 
monthly,  or  graduation)  +  errors  + 
label (s)  +  sequence  +  date  +  system 
+  utility  +  description  +  partition/ 
disk  +  saveset (s) /source (s) 

id(s)  +  (type  =  staff,  faculty, 
student)  +  density  +  loan,  errors  + 
label (s)  +  sequence  +  percent  used  + 
date  +  system  +  utility  +  owner  + 
advisor  (if  student)  +  contact  phone 
+  description  +  partition ( s ) /disk ( s ) 
+  saveset (s) /source (s) 

ids 


(type  =  scratch)  delete  backup 
record 

(type  =  empty)  delete  physical 
and  backup  record 


C.  DFD  DATA  DICTIONARY 


Advisor 
Contact  Phone 
Date  of  Errors 

Date  of  Graduation 

Date  Loaned 
Date  Received 

Density 

Description 

Disk 

Errors 

Estimated  Date  of 
Return 


Identification 
Number  (id) 


=  The  name  of  a  student's  advisor 

=  The  phone  number  of  the  owner 

=  The  date  the  errors  were  provided  by 
the  utility 

=  The  graduation  date  of  the  students 
whose  files  are  contained  in  a 
graduation  backup  tape 

=  The  date  a  tape  is  loaned 

=  The  date  the  tape  was  received  by  the 
1.  ibrary 

=  The  bits  per  inch  which  may  be  read  to 
tape 

=  Notes  by  the  librarian  regarding  the 
software 

=  Used  with  the  VMS  operating  system  to 
define  a  major  subdivision  of  files  of 
disk 

=  The  number  of  "bad  bits"  on  a  physical 
tape.  The  figure  is  provided  by  the 
utility  when  a  tape  is  read  or  written 

=  The  date  the  librarian  assigns  as  the 
date  the  tape  should  be  returned  to  the 
library 

=  A  unique  number  assigned  a  slot  in  the 
cabinet.  Slots  are  numbered  consecu¬ 
tively  left  to  right,  top  to  bottom,  so 
the  number  may  be  used  to  locate  the 
slot.  When  a  tape  is  logged  into  the 
library  it  is  assigned  the  identifi¬ 
cation  number  of  the  slot  in  which  it 
is  stored. 
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Label 


Length 


Loaned 


Loanee 

Loanee  Contact 
Phone 

Owner 

Partition 


Percent  Used 


Retirement  Date 


Saveset 


Software 


Source 


System 


Type 


=  The  VMS  operating  system  requires  that 
each  tape  be  assigned  a  "label"  by  the 
librarian.  When  the  tape  is  mounted, 
the  label  verifies  to  the  system  that 
the  tape  is  VMS.  If  the  "copy"  utility 
is  used  to  read  or  write  the  tape,  the 
label  must  be  entered  by  the  librarian 
when  mounting  the  tape. 

=  The  total  length  of  a  reel  of  tape 

=  Whether  or  not  the  tape  is  loaned  from 
the  library 

=  The  person  to  whom  the  tape  is  loaned 

=  The  phone  number  of  the  loanee 


=  The  name  of  the  owner  of  the  tape 

=  Used  by  the  UNIX  operating  systems  to 
define  a  major  subdivision  of  files 

t 

=  The  percent  of  the  tape  containing 
backup  data 

=  The  date  the  librarian  assigns  to  the 
tape  for  retirement 

=  Used  with  the  VMS  "backup"  utility  to 
mark  the  beginning  of  each  file  or  set 
.of  files 

=  The  name  of  the  software  on  the  tape 

=  Used  with  other  than  VMS  operating 
system,  and  "backup"  or  "copy"  utili¬ 
ties  to  describe  a  file  or  set  of  files 
on  a  tape 

=  The  combination  hardware  and  operating 
system  by  which  the  tape  data  may  be 
read  or  written 

=  The  use  of  a  tape  maintained  by  the 
1 ibrary 


•W*? 


o 


Type 

Daily 

Disks  are  read  to  tape  each  day.  These 
daily  tapes  are  written  to  one  set  of 
tapes  each  week  and  identified  as  a 
daily  backup 

Type 

Graduation 

= 

A  backup  tape  containing  disk  files  of 
students  of  a  graduated  class 

Type 

Individual 

= 

The  type  tape  is  an  individual  staff, 
faculty,  or  student's  backup  tape 

Type 

Monthly 

= 

Each  month,  all  disks  are  read  to  tape 
and  identified  as  monthly  backups 

Type 

Scratch 

Blank  tapes  assigned  to  slots  in  the 
library  available  to  read  data  from 
disk 

Type 

Vendor 

= 

Tapes  containing  vendor  software 

Type 

Weekly 

= 

Each  week,  all  disks  are  read  to  tape 
and  identified  as  a  weekly  backup 

Utility 

= 

The  software  utility  which  must  be  used 
to  read  or  write  the  tape  data 

Vendor 

= 

The  name  of  the  company  which  produced 
the  software 

III.  LOGICAL  SCHEMA 


IV.  DESIGN 


In  this  chapter  the  design  of  the  TLS  is  described  in 
detail.  First  the  logic  of  the  design  is  discussed.  It  is 
followed  by  a  description  of  the  tables.  A  chart  of  the 
application  module  and  a  description  of  each  frame  is  pro¬ 
vided.  The  modules  association  with  the  functions  described 
by  the  DFDs  are  provided  by  charts.  Integrity,  security, 
the  database  administrator,  and  validation  and_ test  are  dis¬ 
cussed.  The  design  data  dictionary  and  frames  definition  are 
derived  from  this  chapter  and  are  provided  in  Appendices  C 
and  D  for  ease  in  future  reference. 

A.  LOGIC  OF  THE  DESIGN 

Several  factors  were  considered  before  mapping  the  logi¬ 
cal  schema  to  the  Ingres  database.  They  were  prioritized  as 
f o 1  lows : 

User 

Interactive  standardization  and  validation  of  input 

Simplicity 

Librarian  functions 

Ingres 

Database  requirements 
Query  by  forms  (QBF)  limitations 
Report  by  forms  (RBF)  flexibility 
Applications  by  forms  (ABF)  capabilities 

Logical  Schema 
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Non-Standard  record  input,  incorrect  data  input,  and 
an  inability  to  control  the  sequential  consecutive  assignment 


of  identification  (id)  numbers  are  the  major  problems  in  the 
current  library  system.  An  interactive  forms-based  input 
method  with  validation  capabilities  can  correct  these  prob¬ 
lems.  The  TLS  must  be  kept  simple  and  quick  to  facilitate 
tile  task  of  logging  tapes  and  retrieving  data. 

2 .  Ingres 

Ingres  is  a  relational  DBMS.  It  provides  a  means  tc 
store  data  in  tables.  The  basic  method  for  entering,  re¬ 
trieving,  and  manipulating  data  is  by  use  of  its  data  manip¬ 
ulation  language,  "QUEL".  The  user  of  QUEL  must  understand 
the  language  comimands  and  syntax,  and  the  structure  and  con¬ 
tent  of  each  table.  Data  manipulation  with  QUEL  is  too  time 
consuming  and  distracting  for  the  daily  functions  of  the  li¬ 
brarians.  However,  Ingres  provides  Query  By  Forms  (QBF),  an 
automated  forms  processing  interface,  which  simplifies  da*:? 
~u;r.ipulation .  The  user  may  interactively  append, 
replace,  or  retrieve  data  from  one  table  at  a  tim.e  in 
database  without  knowledge  of  QUEI.. 

Q'BF  provides  an  automated  method  for  the  functicn:-:  ■ 
a.mcend,  query,  update,  and  deletion  of  values  of  records  oi 
'ne  table  at  a  ‘■ime.  It  presents  forms  to  ti:e  uc'r 

fields  frc";  ^nc  ricnror'r ia te  ‘■able.  P"  ie'hiul-. 


may  be  edited  by  the  application  developer  by  using  the 
Visual  Forms  Editor  (VIFRED)  to  limit  the  data  the  user  can 


input  or  manipulate.  The  editing  capabilities  include  the 
deletion  or  addition  of  fields  in  a  form,  definition  of  fielc: 
parameters,  and  definition  of  field  attributes  for  valida¬ 
tion,  mandatory  input,  error  messages,  automatic  repetition 
of  field  values,  and  special  display  modes. 

QBF  requires  different  user  procedures  for  each  of 
its  functions.  The  Append  function  must  be  used  for  initial 
entry  of  a  record.  The  Append  function  has  an  autcr.ated 
facility  which  simplifies  the  sequential  input  of  reccrds 
which  have  many  fields  of  equal  value.  After  the  first 
record  is  entered,  the  user  may  duplicate  the  field  values  ir 
subsequent  records  by  pressing  a  f unction ■ key .  This  simpli¬ 
fies  input  and  can  be  used  to  remind  the  user  of  the  previc’us 
value  input. 

The  Update  function  must  be  used  in  QBF  to  replace  or 
delete  values  in  existing  records.  When  using  Update,  the 
first  display  of  fieU-.s  is  presented  for  the  user  tc 
t..e  record  or  records  desired.  After  the  query  is  entered, 
Ingres  retrieves  the  records  and  displays  them  on  the  ter¬ 


minal,  one  at  a  time,  for  update.  Update  dees  net 
duplication  facility. 

F'-.u.  r  1  imi  t  a  t  iens  cf  Q'BF  greatly  affected 
dr  1 ' :  ‘  I  c  field  value  ;  u r  1  i  ca  t  i •'  n  f  a c  i  i  1 1  ’  t  a ■  ■ 


query  in  the  Update  function,  they  appear  on  the  terminal  one 
at  a  time.  This  format  is  not  useful  for  reports  or  records; 
3)  QBF  only  allows  manipulation  of  data  on  one  table  a"  a 
time;  and  4)  QBF  does  not  provide  for  any  internal  mani¬ 
pulation  and  assignment  of  data  values. 

Report  By  Forms  (RBF)  is  a  forms-based  record  speci¬ 
fier  available  for  retrieving  reports  without  knowledge  cf 
QUEI..  RBF  allows  the  developer  to  select,  design,  and 
present  multiple  record  reports  from  one  table  at  a  time, 
through  the  use  of  views.  RBF's  facility  to  present  reports 
with  data  from  multiple  tables  greatly  influenced  the  design 
of  the  application. 

The  developer  may  integrate  the  functions  and  fortis 
of  QBF  and  RBF  into  a  single  application  by  using  Ingres 
Applications  By  Forms  (ABF) .  The  application  uses  forms  as 
the  vehicle  for  interaction  between  the  application  and  user. 
The  user  uses  menus  to  select  operations  desired  and  forms  to 
append,  query,  or  update,  or  to  retrieve  reports  fr.-'rr  f-i  r- 
latabao-;.  Knowledge  of  QUEL  is  not  required.  AB!'  a.!  ha ii 
developer  greater  flexioility  than  the  functions  availar'.-  -  a 
ioF  and  REF.  RBF,  however,  was  sufficient  for  tiae  lihr-ry  .  n 
certain  cases,  wiiereas  QBF  was  no*-.  Ir-.  most  earec,  :  “ 


impossiole  to  matcii  a  task  with  only  cHf'  ‘:a':;h-.  In 
"ask  woula  have  required  tne  l:orarian  "o  r  r’- 


librarian.  Additionally,  the  assignment  of  id  numbers 
required  control  to  prevent  duplication  and  ensure  consecu¬ 
tive,  sequential  numbers.  This  required  a  search  of  current 
id  numbers,  a  possible  arithmetic  operation  on  the  maximum  iJ 
and  assignment  of  the  result  to  the  form.  ABF  enables  such 
flexibility  by  allowing  development  and  integration  of  proce¬ 
dures  into  the  application  by  the  developer.  The  procedures 
may  be  used  with  forms  developed  by  the  use  of  VIFRED.  The 
forms  have  the  sam.e  capabilities  as  those  described  accve. 
Al'F  will  he  discussed  further  in  Section  D. 

3 .  I.ogical  Schema 

a.  Data  Class  TAPE 

The  data  class  TAPE  was  mapped  intact  to  table 
TAPE  in  the  logical  schema.  The  fields  values  in  table  TTPS 
provide  physical  tape  characteristics  which  retain  tre:r 
importance  throughout  the  life  of  the  tape's  existence  in  the 
library  whether  or  not  any  data  on  the  tape  is  of  importance 
to  the  library, 

Tne  TAPE  table  stores  all  of  ti:e  :  nu: 

r;S3i;jned  in  the  library.  As  discussed  above,  ass : 

*-apes  *:c  id  nuncers,  and  the  addition  of  nvo,-.'  ids  tc 
:.;r5ry  are  controlled  by  the  application.  The  iioiiridn  aoI’ 
r;;'pically  enter  tne  values  (id,  length,  and  bpi  )  of  ti'o  T.'i: 


the  field  attribute  of  repeating  values  to  the  form  defini¬ 
tion.  Data  integrity  and  future  retrieval  is  assured  by 
writing  validation  criteria  into  the  form  definition.  Two 
fields,  errors  and  date  of  errors,  are  entered  and  maintained 
by  the  librarian  at  other  times  -  after  the  tape  is  read  or 
written.  As  a  separate  task,  the  record  is  updated.  After 
an  active  tape  is  retired,  but  the  physical  tape  is  retained 
by  the  library  for  rewrite,  all  of  the  values  in  TAPE  are 
retained.  If  the  tape  is  thrown  away,  all  of  the  values  of 
TAPE  are  updated  to  null  except  the  id  number  which  is  re¬ 
tained.  Such  an  id  number  is  known  as  an  empty  slot  and  will 
be  used  by  the  application  for  future  assignment  to  a  new 
scratch  or  vendor  tape. 

o.  Data  Class  SET 

Data  class  SET  m.ust  be  related  to  TAPE  so  that 
the  id  number  in  SET  allows  the  librarian  to  access  the  phy¬ 
sical  characteristics  in  TAPE  when  a  tape  is  to  be  read  cr 


wr i t  ten  . 


accorc.ir.a  tc  i 


k'i-/  to  ^lata  class  SET  is  Ic!' 


tvT'.e  acti'/e  tane.  Therefore, 


iO!;:eo  to 


‘  n  ti-  r 


1  a.  I..  I 


i  j  ■  :i 


i  r.  ct  e  Ci  a  t  a  c  1  a  s  s  A  C  T I  \  . 


L  r  r.  va  i  u  e  3 


iele^ed  at  the  same  rime  as  SET,  and  since  ACT  IT 


1  i  ~a  I  1 7 


r'^la»-ed  to  SET,  i 


a  ‘  na:;ied  Sc.TP. 


tapes  are  added,  SETS  values  are  appended  to  the  SETS  table 
by  the  application. 


The  timing  for  entering  backup  tape  data  is 
different.  In  ordei'  to  read  a  backup  to  tape,  the  librarian 
must  first  find  an  appropriate  scratch  tape  in  table  TAPE. 
New  records  are  added  to  table  SETS  using  QBF-append .  As 
each  record  is  added  for  each  id,  common  values  (those  of 
data  class  SET)  are  automatically  called  to  the  form  after 
the  first  entry.  Only  the  fields  expected  to  be  different 
for  each  id  (those  of  data  class  ACTIVE  TAPES)  will  be 
entered  by  the  librarian.  If  the  librarian  loses  track  cf 
which  id  was  previously  entered,  (s)he  may  use  the  function 
key  to  recall  it. 

c.  Data  Class  FILE  PATH 

Data  class  FILE  PATH  is  contained  in  table  FILE. 
There  are  many  file  paths  on  one  active  tape  or  one  file  path 
on  several  tapes  of  one  set. 

Each  FILE  PATH  record  must  be  linked  to  an  ;.C 
number  so  the  librarian  can  locate  the  particular  t-ar'o  i w  > 
on  which  the  file  patli  was  located.  Therefore,  id  was  afnel 
to  table  TAPE.  File  records  are  usually  added  at  the  rare 
tin,e  new  SETS  records  are  added,  i.e.,  wh.en  a  new  venh;cr  r.ao-' 
is  received  or  when  a  new  backup  is  read.  In  this  case,  n-c.. 
FILE  records  ar-.-^  atldied  using  the  CEF-ant'end  function. 

^ae  id  aaay  h.ise  i-any  FilE  records  ,  or  one  Flld'  r’''’. 

.  :sary  i,.s,  no  r  •- '--a  *■' ;  n  ;  valoor  or-'  h'’fin=d  :n 


field  attributes.  The  librarian  may  repeat  values  by  using 
the  function  key.  The  only  exception  to  the  time  of  entry  of 
FILE  PATH  discussed  above  is  on  the  infrequent  occassion  when 
the  librarian  adds  a  new  file  path  to  an  individual's  eld 
tape.  This  task  requires  fields  from  two  tables  to  be 
changed  -  FILE  and  SETS.  In  this  case,  a  separate  procedure 
is  provided  in  the  application  to  ensure  the  integrity  of 
both  tables. 

d.  Data  Class  STUDENT 

Data  class  STUDENT  is  contained  in  table  STUDEl.'T. 
Mew  records  are  added  to  STUDENT  each  time  a  new  graduation 
backup  is  added  to  SETS.  Eventually,  the  librarian  must  find 
on  which  tapes  student  files  are  contained  by  student  name. 
Therefore,  id  was  added  to  STUDENT.  Nev/  records  are  added 
using  ijBF-append.  A  student  may  have  files  on  many  tapes. 
Data  class  STUDENT  fields  are,  therefore,  repeated  by  the 
form  after  the  first  entry. 

e.  Data  Class  LOAN 

Data  class  LCAli  is  included  in  table  LCA;..  ilr 
tapes  are  added  to  table  LOAM  on  an  individual  basis  as  fr- 
quentiy  as  they  are  by  SETS,  id  was  added  to  the  table.  I, 
records  are  added  when  a  tape' is  leaned  usinc  the  bBF-ai:  f-O  d . 
They  are  deleted  when  a  tape  is  returned. 


B.  TABLES  AND  VIEWS 

Initial  input  of  library  data  are  stored  in  the  hash 
storage  structure  in  which  records  are  stored  randomly;  new 
rows  are  added  to  the  bottom.  Therefore,  the  entire  table 
must  be  scanned  for  retrieval.  The  majority  of  retrievals 
and  comparisons  in  the  library  involve  selection  of  records 
based  on  id  number.  Hash  tables  store  each  row  at  an  address 
determined  by  a  column  or  columns  in  a  record.  Records  may 
be  located  directly  by  the  value  of  the  address,  without 
scanning  the  entire  table.  The  hash  storage  structure  car 
greatly  excel lerate  queries  run  on  tables  with  a  large  numcer 
of  rows.  After  the  current  library  is  input,  it  is  recom¬ 


mended  that  all  tables  be  converted  to  the  "hash"  Storage 
Structure  [Refs.  1  and  2] ,  using  the  id  number  as  the 


J) 


"address"  column.  Thereafter,  the  hash  structure  should  be 
miodified  when  20  percent  of  the  table  is  changed.  The  tables 
and  views  are  contained  in  Appendix  B. 


TABLES 

file 

loan 

sets 

student 


VIEWS 

vind 

vloan 

vce 

vretire 
vsc  loan 
vscratch 
vs  tudent 


C.  DESIGN  DATA  DICTIONARY 

The  Specification  Data  Dictionary  (Appendix  A)  defines 
fields  in  terms  of  how  they  are  used  in  the  library.  The 
Design  Data  Dictionary  (Appendix  C)  defines  fields  in  terms 
of  how  they  are  used  in  the  TLS  application.  Both  should  be 
read  for  full  comprehension  of  the  field's  use. 

D.  THE  APPLICATION 

The  tape  library  was  developed  using  Ingres  Application 
By  Forms  (ABF) ,  and  is  an  interactive  application  with  a 
forms  interface.  The  application  user  interacts  with  the 
form  by  filling  in  fields  with  data.  The  application  inter¬ 
faces  with  the  form  by  getting  values  from  it,  and  sometimes 
placing  values  on  it. 

ABF  applications  are  built  by  the  use  of  frames.  The 
frame  is  the  principal  vehicle  for  interaction  between  the 
user  and  the  forms  application.  Each  full  screen  the  user 
sees  is  a  frame.  A  frame  is  composed  of  a  form  and  a  pro¬ 
cedure.  The  upper  portion  of  the  frame  is  the  form. 

The  developer  designs  the  form.  It  may  include  trim 
and/or  fields.  When  defining  a  form  the  developer  only 
includes  the  fields  which  may  be  manipulated  by  the  frame. 
Fields  and  their  attributes  are  included  in  the  form  defi¬ 
nition.  Attributes  include  validation  criteria,  validation 
failure  messages,  and  value  "display  only",  and  m.andatcry 
input  r  equ  i  rem.ents  . 


Below  the  form  on  the  lower  left  of  the  frame  is  a 
command  menu  defined  and  placed  on  the  frame  by  the  proce¬ 
dure.  The  menu  includes  a  list  of  operations  which  the  user 
may  select.  By  selecting  a  command,  another  procedure  is 
called  to  execute  the  operation.  The  library  application 
commands  include  procedures  for  movement  to  other  frames, 
input  or  retrieval  of  data,  and  a  few  arithmetic  operations. 

Frames  may  be  designated  as  one  of  four  types  or  usages 
by  the  developer.  Three  are  used  in  the  library  -  QBF,  RBF, 
and  User  Specified  (User) . 

(1)  QBF  -  When  encountering  a  QBF-defined  frame,  ABF  calls 
on  the  QBF  subsystem.  QBF  allows  append,  query,  and 
update  operations  to  be  performed  on  one  table  of  the 
database.  The  developer  may  limit  which  of  these 
operations  may  be  performed  by  the  frame  when  defining 
the  frame.  A  form  and  one  table  are  associated  with  a 
QBF  frame.  The  procedure  is  automatically  provided  by 
QBF. 

(2)  Report  Writer  -  When  encountering  a  "report"-def ined 
frame  in  the  library,  ABF  calls  on  the  Ingres  RBF  sub¬ 
system.  Reports  and  optional  forms  are  associated 
with  report  frames.  By  defining  the  report,  the 
developer  controls  the  output  mode  format  and  report 
inclusion  and  layout.  The  developer  may  provide  a 
form  in  the  frame  definition.  The  form  allows  the 
user  flexibility  in  report  retrieval.  The  user  may 
select  records  by  field  values  or  ranges. 

(3)  User  -  When  ABF  encounters  a  user-specified  frame,  it 
calls  on  procedures  written  by  the  developer.  Pro¬ 
cedures  and  forms  are  associated  with  user  frames.  In 
the  library,  procedures  are  written  in  either  the  ABF 
Operations  Specification  Language  Code  (OSL)  or  in  a 
combination  "C"  language  and  QUEL.  OSL  simply  calls 
other  frames  or  procedures,  or  exits  from  the  appli¬ 
cation.  "C"  and  QUEL  were  used  where  such  a  program 
would  be  more  efficient,  simpler,  or  more  secure  than 
QBF,  or  where  an  operation  required  data  input  to  or 
retrieval  from  more  than  one  table. 


E. 


FRAMES 


The  frames  of  the  tape  library  are  provided  as  charts  in 
Appendix  D.  They  are  defined  briefly  in  the  frame  descrip¬ 
tion  section  below.  The  frames,  and  their  associated  forms, 
procedures,  reports,  and  tables  are  listed  and  defined  in 
greater  detail  in  Appendix  E. 

F.  FRAMES  DESCRIPTION 

1 .  Topframe  (1) 

Topframe  (1)  is  a  user  frame  which  provides  a  menu 
form.  The  form  spells  out  the  commands  available  in  the 
operations  menu.  The  user  may  select  one  of  six  operations 
Which  call  the  OSL  procedure.  The  first  five  call  another 
frame  -  TQuery/Report  (1.1),  PQuery/Report  (1.2),  Add  (1.3), 
Update  (1,4),  and  Delete  (1,5).  The  last,  Exit,  ends  the 
application. 

2 .  TQuery/Report  (1.1) 

PQuery  (1.1)  and  all  of  its  subordinate  frames  pro¬ 
vide  either  a  path  to  retrieval,  or  retrieval  of  a  report 
from  the  database  to  the  terminal.  Terminal  reports  were 
designed  for  use  by  the  librarian  to  search  the  database  for 
a  particular  tape  or  set  of  tapes.  The  fields,  formats,  and 
sorting  was  selected  for  easy  reference  and  relevance  to  the 
librarian.  PQuery  is  a  User  frame  which  provides  a  menu 
form.  The  form  defines  the  commands  available  on  the  oper¬ 
ations  menu.  The  user  may  select  one  of  nine  cneraticns 


which  call  the  OSL  procedure.  The  first  eight  call  another 
frame  -  Scratch  (1.1.1),  Periodic  (db,  wb,  mb,  gb)  (1.1.2), 
Individual  (is,  if,  iu)  (1.1.3),  Vendor  (1.1.4),  Student 
(1.1.5),  Loaned  (1.1.6),  and  Date  to  Retire  (1.1.7).  By 


selecting  Return,  the  OSL  calls  Topframe  (i; 
the  application. 


Exit  leave: 


(1)  Scratch  (1.1.1),  Periodic  (1.1.2),  Individual  (1.1.3), 
Vendor  (1.1.4),  Student  (1.1.5),  Bac]<up  or  Vendor 
(1.1. 6. 2),  and  Date  to  Retire  (1.1.7).  Each  of  these 
frames  are  report  frames  which  display  a  parameter 
form.  The  form  includes  fields  in  which  the  user  must 
enter  data  to  define  records  to  be  included  in  the 
report.  RBF  provides  three  commands  at  the  bottom  cf 
the  form.  Help,  Report,  and  End.  Help  provides  the 
user  with  assistance.  Report  enters  the  parameters 
and  causes  the  appropriate  data  to  be  listed.  End 
returns  to  the  previous  frame.  The  fields  and  field 
attributes  of  each  form  and  the  report  definitions  are 
proviaed  in  Appendix  E  under  the  appropriate  frarre 
definition  . 

(2)  Loaned  (1.1.6)  is  a  User  frame  which  provides  a  nieru 
form.  The  form  lists  four  commands  available  on  tre 
operations  menu.  The  user  may  select  one  cf  the 
operations  to  call  an  CSI,  procedure.  The  first  throe 
f  .■  1  1  another  frame  -  Scratch  f  1.1. 6.1)  and  Ea~’’_u’' 


Vendor  (1.1. 6. 2).  Return  calls  the  previous  frame 
TQuery/Report  (1.1).  Exit  terminates  the  application. 

(3)  Scratch  (1.1. 6.1)  is  a  report  frame  which  has  no  asso¬ 
ciated  form  for  parameter  selection.  RBF  presents  a 
command  menu  with  the  commands  Help,  Report,  and  End. 
Help  provides  assistance  to  the  user.  Report  causes 
the  loaned  scratch  tape  report  to  be  listed  on  the 
terminal.  End  calls  the  previous  frame  -  Loaned 
(1.1.6).  The  report  fields  and  format  are  described 
in  Appendix  E  under  the  appropriate  frame  definition. 

3 .  PQuery/Report  (1.2) 

PQuery/Report  (1.2),  and  all  of  its  subordinate 
frames,  provide  either  a  path  to  retrieval,  or  retrieve  a 
report  from  the  database  to  a  file  in  the  librarian's  per¬ 
sonal  UNIX  workspace.  The  librarian  may  then  print  the  file 
using  the  UNIX  operating  system.  The  primary  reason  for  pro¬ 
viding  printed  reports  (except  in  the  case  of  dump  reports) 
was  to  provide  a  means  for  the  librarian  to  communicate  with 
library  users.  Therefore,  the  fields,  format,  and  sorting 
was  selected  to  group  data  in  a  format  relevant  to  us-^ts. 
Dump  reports  were  designed  to  provide  the  librarian  wdth  ? 
printed  list  of  each  relation  in  a  format  which  would  facil¬ 
itate  comparisons  betv/een  relations.  All  printed  reports 
designed  to  conserve  paper.  Ingres  docume nt a 1 1 c r.  dt- 
s  a  m^f-nod  for  printinc:  reports  direcilv  :  ~  .'-.f. 
r,  ~:;ts  mo  ti'icd  does  net  worm  because  :i  : 


were 


in  all  of  the  current  Ingres  versions.  It  will  be  corrected 
in  the  upcoming  Version  III.  Therefore,  this  slightly  more 

cumbersome  method  of  "write  to  file"  was  used.  TQuery  is  a 

User  frame  which  provides  a  menu  form.  The  form  spells  out 
the  operations  available  on  the  command  menu.  The  user  may 
select  one  of  nine  operations  which  call  the  OSL  procedure. 
The  first  nine  call  another  frame  -  Scratch  (1.2.1),  Periodic 
(1.2.2),  Individual  (1.2.3),  Vendor  (1.2.4),  Student  (1.2.5), 
Loaned  (1.2.6),  Date  to  Retire  (1.2.7),  Dump  (1.2.8).  Return 
calls  the  previous  frame.  Exit  terminates  the  application. 

(1)  Scratch  (1.2.1),  Periodic  (1.2.2),  Individual  (1.2.3), 
Vendor  (1.2.4),  Student  (1.2.5),  Baclcups  or  Vendor 

(1.2. 6. 2) ,  and  Date  to  Retire  (1.2.7).  Each  of  these 

frames  are  report  fram.es  which  display  a  parameter 

form.  The  form  includes  fields  in  which  the  user  must 

enter  data  to  define  the  records  to  be  included  in  the 

report.  It  also  provides  the  name  of  the  output  files 
to  the  user.  RBF  provides  three  commands  at  t'r.e 
Let  ton.  of  ♦rne  form  -  I'olp,  Report,  and  End.  Help  pro¬ 
vides  assistance  to  the  user.  Report  enters  the  p-.r- 
a.meters,  selects  data,  ana  writes  tne  report  to  file. 
End  returns  to  the  previous  frame  -  PCuery,' Repor  “ 

(1.2) .  Th.e  reports  definitions  are  provided  ;  r. 

P  po  n  c.  1 X  F. 

iZ]  Loured  (  1  .  2  . -1  i  is  .a  User  frune  wi-;  ich  orovides  ?  n  o". 


u-  Lv  r-r o-  .v  .no--  .v  .s  .v  . .  e  .  • 


command  menu.  The  first  two  call  the  OSL  to  call 
frame  Scratch  (1.2. 6.1)  or  Backup  or  Vendor  (1.2. 6.2). 
Return  returns  to  the  previous  frame  -  PQuery/Report 
(1.2).  Exit  terminates  the  application. 

(3)  Scratch  (1.2. 6.1)  is  a  report  frame  which  provides  a 
form  that  communicates  the  name  of  the  output  file  of 
the  report  to  the  user.  RBF  provides  three  operations 
on  the  command  menu  -  Help,  Report,  Return.  Help  pro¬ 
vides  assistance  to  the  user.  Report  writes  a  report 
of  scratch  tapes  to  the  output  file.  End  ret”.rns  tc 
the  previous  frame  -  Loaned  (1.2.6) 

(4)  Dump  (1.2.8)  is  a  User  frame  which  provides  a  menu 
form  which  writes  out  the  operations  included  in  the 
command  menu.  The  first  six  call  frames  -  Tape 
(1.2. 8.1),  Sets  (1.2. 8. 2),  File  (1.2. 8. 3),  Student 
(1.2. 8. 4),  and  Loan  (1.2. 8. 5).  Return  calls  PQuery/ 
Report  (1.2).  Exit  terminates  the  application. 

(5)  Tape  (1.2. 8.1),  Sets  (1.2. 8. 2),  File  (1.2. 8. 2), 

Student  (1.2. 8. 4),  and  Loan  (1.2. 8. 5)  are  r-uort 
frames  which  provide  the  name  of  the  output  file  t;- 
the  user.  REF  provides  the  operations  on  ti'.e  ccmirar.d 
menu  -  Help,  Report,  and  Return.  Help  provider 
assistance  to  the  user.  Report  selects,  sorts,  and 
v/rites  the  report  ‘:o  file.  Return  calls  the 
’.'icus  Lrame  -  Cump  (1.2.8).  Pr.-'"  report  defin;- 

include'.;  in  d;cendi:-:  F. 


4.  Add  (1.3) 

Add  (1.3),  and  all  the  frames  subordinate  to  it,  pro¬ 
vide  the  means  or  a  path  to  a  means  for  the  librarian  to  add 
a  new  record  to  a  table  or  to  more  than  one  table  of  tlie 
database.  Add  is  a  User  frame  which  provides  a  menu  forn- 
that  defines  the  operations  available  on  the  command  menu. 
The  user  may  select  one  of  seven  operations.  All  call  t;-.£ 
OSL  to  call  a  frame  -  Scratch  (1.3.1),  Vendor  (1.3.2),  Backup 
(1.3.3),  Files  (1.3.4),  Students  (1.3.5),  Loan  (1.3.6). 
Return  calls  the  previous  frame  -  Add  (1.3). 

(1)  Scratch  (1.3.1)  is  a  User  frame  with  a  form,  and  three 
procedures.  The  form  provides  fields  for  data  input 
into  one  table.  The  first  procedure  is  an  OSL  pro¬ 
cedure  which  provides  a  command  menu  at  the  bottom  of 
the  form  of  three  operations  -  Id,  Add,  and  Return. 
By  selecting  Id,  the  OSL  calls  on  procedure  sgetid. 
The  purpose  of  sgetid  (and  vgetid  (1.3.2))  is  to  en¬ 
sure  empty  slots  of  the  library  are  filled  and  tha*- 
new  ids  assigned  are  the  maximum  id  plus  one.  Lev;  :  .Ir 
are  assigned  to  tiie  database  only  when  scratch 
or  vendor  tapes  are  added.  Sgetid  id  (like  vqeriu  :  ,1 
in  frame  1.3.2)  assigns  the  id  labels  tc  "apec  or 
tapes  and  slots  and  informs  the  librarian  of  ‘u'.e  cli 
or  r-^w  id,  Sgetid  places  the  id  on  t;  fcrm  or  ) 
io:,:ots  ^ne  u.;-r  **  ■''  enr^ir  new  data  and  ,-oh;>o‘-  d  :  . 


ni:  oc-,:  'ir 


updates  the  fields  of  an  empty  slot  record  in  the  TAPE 
table  or  appends  a  new  record  to  the  TAPE  table  if  the 
entered  data  meets  the  procedure  and  form  validation 


criteria.  It  informs  the  user  of  the  action  taken  and 
what  labelling  action  the  librarian  should  take.  By 
selecting  Return,  the  previous  frame  -  Add  (1.3)  is 
cal  led . 

Vendor  (1.3.2)  is  a  user  frame  with  a  form  and  three 
procedures.  The  form  provides  fields  for  data  input 
to  two  tables.  The  first  procedure  is  an  OSL  pro¬ 
cedure  which  provides  a  command  menu  at  the  bcttom  of 
the  form  which  includes  three  operations  -  Id,  Add, 
and  Return.  By  selecting  Id,  the  CSL  calls  on  proce¬ 
dure  vgetid  which  retrieves  the  lowest  empty  slot,  or 
new  id  number  from  the  database  and  puts  it  on  the 
form.  It  tells  the  user  if  the  id  is  that  of  an  empty 
slot  or  a  new  id  and  prompts  the  user  to  enter  the 
new  input  and  select  Add.  By  selecting  Add,  the  CSL 
calls  procedure  avendorc  which  enters  the  new  la*- 
on  the  tv;o  tables  if  it  meets  the  field  attrihuri*  ar.  I 
ti;e  procedure's  validation  criteria.  The  prcceluri 
proiTipts  the  user  to  inform  him,  or  her  of  action  . 
By  selecting  Return  the  previous  frame  -  Add  (1.?)  i.- 
ca 1 1 ed  . 

i'ack':p  [1.1.2)  is  a  User  frame  ui' ich  rr'  Viljo  i  ; 


OSL  procedure.  The  OSL  procedure  provides  a  command 
menu  of  three  operations  on  the  bottom  of  the  form 
which  call  other  frames  -  Periodic  (1.3. 3.1),  Indivi¬ 
dual  (1.3. 3. 2),  and  Return  to  the  previous  frame  -  Add 
(1.3.3)  . 

Periodic  (1.3. 3.1),  Sets  (1.3. 3. 2),  New  Baclcups  or 
Vendor  (files)  (1.3. 4.1),  Students  (1,3.5),  and  Lean 
(1.3.6),  are  QBF-append  only  frames.  Each  frame  pro¬ 
vides  a  form  for  data  input.  QBE  provides  a  command 
menu  at  the  bottom  of  the  form  which  includes  three 
operations  -  Help,  Add,  and  Return.  Help  provides 
assistance  to  the  user  in  the  use  of  QBE.  Add  appends 
the  data  to  the  appropriate  table.  Return  returns  tc 
the  previous  frame. 

Files  (1.3.4)  is  a  User  frame  which  provides  a  menu 
form  which  writes  out  the  operations  provided  by  the 
OSL  in  the  command  menu.  The  OSL  provides  three 
operations  which  call  frames  -  Periodic  (1.3. 3.1), 
Individual  (1.3. 3. 2).  Return  calls  tne  previcus  fr'-'-'i 
-  Add  (1.3)  . 

Old  Partial  Individual  (1.3. 4.2)  is  a  User  frame  with, 
a  form  and  tvvo  procedures.  The  form  provides  fiel  .s 
and  validation  criteria  for  data  input  to  tv/c  tables. 
The  OSI,  nrocedur-^  sTcvides  t'nree  ontrations  cr.  * 


sets  table.  Return  calls  the  previous  frame  -  Files 
(1.3.4).  Exit  terminates  the  application. 

5 .  Update  (1.4) 

Update  (1.4),  and  the  frames  subordinate  to  it,  allow 
the  librarian  to  update  selected  information  in  the  database. 
The  data  may  require  update  because  the  values  changed  since 
they  were  entered  or  because  they  were  entered  incorrectly. 
Update  is  a  User  frame  with  a  menu  form  and  an  OSL  procedure. 
The  form  writes  out  the  four  operations  provided  by  the  CSL 
in  the  command  menu.  The  first  four  call  the  OSL  to  call 
other  frames  -  Errors  (1.4.1),  Backup  (1.4.2),  and  Loan 
(1.4.3).  Return  calls  the  previous  frame  -  Topframe  (1). 

Errors  (1.4.1),  Backup  (1.4.2),  and  Loan  (1.4.3)  are 
QBF  update  only  frames.  Each  has  one  form  which  provides 
selec.ted  fields  which  enable  update  of  one  table  by  the 
librarian.  QBF  provides  the  command  line  which  prompts  the 
user  for  query  of  the  old  record,  then  update. 

6 .  Delete  (1.5) 

Delete  (1.5)  is  tlie  only  frame  which  allows  delsticc 
cf  records  from  the  database  tables.  Delete  is  a  User  fra'.ro-' 
with  a  form  and  four  procedures;  tdelete.osl,  dloanc,  dbackc, 
and  dtapec.  The  form  provides  a  field  and  lists  the  oper¬ 
ations  in  the  command  menu  provided  by  the  OSL  procedure.  Th- 
user  en.ters  into  thi^  field  the  id  number  of  the  tore  f-'o 


ch  r -cords  'cill  be  .oelet-d. 


L.  or:,ceuur-^ 


dloanc  which  deletes  records  from  the  LOAN  table.  Backup 
calls  procedure  dbackc  which  deletes  records  from  the  SETS, 
STUDENT,  and  FILE  tables.  Tape  calls  procedure  dtapec  which 
deletes  records  from  the  SETS,  FILE,  STUDENT,  and  LOAN  tables 
and  all  fields  from  the  TAPE  table  except  id.  The  id  number 
in  the  TAPE  table  will  then  be  an  empty  slot. 


DFDS/FRAMES 


FUNCTION 


PROCESS 


FRAME 


i!.  INTEGRITY 


2,  3,  8 
2,  3,  8 


3.2,  1.3. 4.1,  1.4.1 
1 

3.1,  1.3. 3. 2,  1.3. 4.1, 
5,  1.4.1 

2,  1.1.3,  1.1.4,  1  .1.5 
1 

1,  1.1.3,  1.1.4 
6 

6.1,  1  .1.6.2 


2,  1.1.3,  1.1.4 


)atabase  integrity  is  maintained  in  seven  ways. 

Permits  are  defined  to  allow  only  the  I'lbrarian.; 
perform  any  functions  on  the  tables  of  the  TI.S. 


'il  A]  but  two  fie  Lis  are  ll:r,  i*'.ed 


or:.-  one 


The  student  record  is  created  when  the  student  gradu¬ 
ates.  At  that  time,  all  of  their  files  are  written  to 
the  graduation  backup,  including  any  individual  stu¬ 
dent  backups  they  may  have  owned.  All  SET  records 
regarding  the  student  are  deleted  at  this  time  (in¬ 
cluding  the  SET  contph) .  Therefore  when  the  student's 
contph  number  is  entered  to  STUDENT,  it  no  longer  is 
recorded  in  SET. 

Data  is  validated  upon  input.  Where  allowed  values 
were  limited  and  known  not  to  change  frequently,  vali¬ 
dations  were  defined  in  forms.  They  are  listed  in 
Appendix  E. 

"Repeat  previous  value  facility".  Librarians  have 
many  other  duties  which  may  distract  them  while  enter¬ 
ing  data  on  a  form.  To  remind  them  of  their  previous 
entry,  they  may  simply  press  a  function  key  for  a  dis¬ 
play  of  previous  fields  entered  when  using  QBF-append. 
Programming.  To  ensure  the  consecutive,  sequential 
assignment  of  ids  tc  cabinet  spaces  and  new  tapes,  t:- 
assignment  is  performed  by  the  application. 

Update.  Values  which  change  in  tb.e  course  of  time,  c  r 
values  which  have  no  validation  on  input  may  be  up¬ 
dated  by  the  librarian  by  using  the  update  frames. 

The  'Jump  rep(.;rts  provide  listings  of  all  *-  u  les  ser*:  •; 

:  :  niuri.'^r.  Ti'-^  licrarian  me'/  us.-‘  f  .  -  ■  -  '  r  ’u 


SECURITY 


I . 


As  discussed  in  Section  H,  only  personnel  to  whom  permits 
have  been  granted  may  affect  the  tables  of  the  database. 
Only  the  librarians  are  assigned  permits.  Any  additional 
security  measure  is  login  symbols.  Login  symbols  provide 
access  to  the  application. 

A  login  symbol  is  defined  in  the  login  files  of  each  of 
the  librarians  to  grant  them  access  to  the  TLS .  No  one  else 
may  gain  access. 


J.  DATABASE  ADMINISTRATOR 

The  database  administrator  will  perform  the  following 
functions  to  maintain  the  TLS. 

(1)  Implementation  -  instructions  for  implementation  are 

provided  in  Appendix  F. 

(a)  Load  the  current  library  records 

(b)  Change  the  storage  structure  of  all  tables 

(2)  Maintenance  -  Instructions  for  maintenance  of  the 

library  are  included  in  the  tutorial  in  Appendix  G 

(3)  To  maintain  peak  performance,  system  mcclifica- 
tions  must  be  run  on  each  table  when  20  percent 
of  the  records  in  the  table  have  been  changed. 
Monthly  system  modifications  are  recommended  in 
the  tutorial . 

(b)  Maintain  the  integrity  of  the  library  by  destroy¬ 
ing  and  defining  permits  to  tables  as  personnel 
are  relieved  of  tlieir  librarian  duties  and  new 
librarians  are  assigned. 

(c'l  Define  the  TLS  login  syirboi  j  lc;ir  i':'. 

n-v  librarians  assim'^d.  -  ■  ■  ■; 


.■v. 


•  J  -i'.  M  S  -  -  -  -  - 


K.  VALIDATION  AND  TEST 


Frames  were  developed  in  a  top-down  fashion,  Topframe 
and  each  of  the  menu  frames  first.  Append  frames  were  then 
developed  and  tested.  Records  of  34  tapes,  backup  data,  and 
associated  data,  were  entered  into  the  library  using  the  new 
frames.  The  update  frames  were  then  tested.  The  librarian 
verified  the  functionality  of  the  frames  and  appropriateness 
of  the  fields.  The  terminal  report  frames  were  then  develop¬ 
ed  and  tested  followed  by  the  printed  report  frames.  The 
librarian  verified  the  reports'  inclusion  and  format.  All 
frames  were  tested  together  using  the  small,  representative 
library  data  and  a  scenario  of  the  various  processes  per¬ 
formed  in  the  library. 

Various  bugs  in  the  Ingres  DBMS  were  discovered  during 
testing ; 

(1)  The  Ingres  documentation  does  not  describe  how  to 
select  records  from  one  table  which  are  not  in  another 
table.  This  was  resolved  by  an  Ingres  representative. 

(2)  The  VM  UNIX  Version  2.1/15VE.04  interface  between  ABF 
and  QBF  malfunctions.  A  corrected  version  has  been 
sent  to  NPGS. 

(a)  In  QBF-update  mode,  updates  were  not  performed. 

(b)  In  QBF  -  all  modes,  validations  could  not  be  per¬ 
formed  between  sets. 

(3)  The  Ingres  documentation  does  not  describe  how  to 
interface  parameter  forms  with  RBF  reports.  An  Irqres 
representative  explained  the  procedure. 

I  4 )  A  known,  bug  exists  in  the  RBF  facility.  Tlu-  do~ur:'-r- 
lafion  describes  hew  to  flac  Ingres  ceheut 
,:;rec*:ly  to  a  printer.  The  process  is  cc'ied  irc-'r- 
r-ctly  and  will  nef;  be  corrected  unt-il  ‘l.e  n^xn 

'll 


version  of  Ingres,  Version  III  is  developed.  There 
fore,  the  TLS  outputs  reports  to  be  printed  to  the 
user's  UNIX  workspace.  The  report  must  then  be 
printed  from  UNIX. 


V.  RECOMMENDATIONS  AND  CONCLUSIONS 


Recommendations  regarding  the  use  of  the  TLS,  observa¬ 
tions  regarding  Ingres,  and  an  opinion  on  use  of  the 
requirements  analysis  and  design  process  are  presented. 

A.  THE  LIBRARY 

The  tape  library  system  (TLS)  is  desigr.-^d  to  enable  the 
Computer  Science  Department  to  provide  secure,  dependable 
library  services.  They  may  do  so  by  implementing  the  TLS 
described  in  this  thesis,  and  by  locking  the  cabinets  in 
which  they  keep  the  tapes.  There  are  ways,  however,  in  which 
data  can  be  entered  incorrectly.  They  exist  because;  1) 
either  there  is  no  means  of  validating  the  entry;  2)  the 
likelihood  of  making  the  error  can  be  reduced  by  methods 
other  than  validation;  or  3)  the  potential  error  is  not 
critical  or  can  be  easily  recognized  and  corrected  by  the 
librarian . 

(1)  Ingres  forms  allow  validations  which  refer  to  other 
fields  in  the  same  or  other  tables.  However,  these 
values  are  recorded  for  comparison  at  the  time  the 
form  is  initialized.  Forms  are  initialized  when  CFjF 
is  called.  Therefore,  when  adding  records  to  a  se*-, 
the  values  added  after  yPF  was  called  will  no*'  re 
includ'wj  in  validation.  Tables  whe"'::  v--  ;  e. 
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values  through  QBF-append  (SETS,  FILE,  LOAN,  STUDENT) 


r 


are  vulnerable  to  this  lack  of  validation.  Double 
entries  of  id  numbers  or  entry  of  id  numbers  which  are 
not  logged  in  the  library  can  occur.  This  likelihood 
is  kept  low  because  of  the  two  procedures  provided  in 
a.  and  b.  below.  If  either  error  occurs,  it  may  be 
caught  and  corrected  by  c. 

(a)  In  order  to  write  a  backup  the  librarian  must  get 
a  scratch  tape  and  an  id  number.  They  must  be 
found  in  the  scratch  tape  list,  there  is  no  other 
place  to  find  available  tapes  or  id  numbers.  The 
scratch  tape  list  is  created  and  maintained  by 
the  application  and  has  very  tight  ‘integrity. 

(b)  If  the  librarian  is  entering  records  into  the 
tables,  and  forgets  the  last  id  number  entered,  a 
control  func-tion  may  be  used  to  see  which  was  the 
last  id  number  entered. 

(c)  If  an  id  is  listed  in  SETS,  FILES,  STUDENT,  or 
LOAN  which  was  not  assigned  in  the  library  or 
which  duplicated  a  previously  assigned  number  it 
will  be  discovered  when  a  routine  backup  or 
vendor  report  is  run,  or  when  the  librarian  runs 
a  dump  of  the  table. 

Librarians  occassional ly  enter  the  wrong  dates,  espe¬ 
cially  the  year.  Ingres  does  not  allow  ar  i  tl";';ei:  ic 
operations  on  dates  in  QBF  validation.  Therefore,  ti;.; 
application  will  not  validate  date  input.  Hcwever, 
current  date  entry  errors  are  quickly  discovered  i  r. 
the  library.  In  the  TLS  they  may  be  corrected  usirrr 
the  update  frames. 

When  reports  are  retrieved  by  selecting  parameters  r-; 
•/alue,  the  value  must  -nact  *  f  'r  a;  1  v'  e 


letter  or  any  word) .  Upper  case  letters  are  consider¬ 
ed  different  than  lower  case.  It  is  recommended  that 
all  entries  be  in  lower  case  letters  and  that  the  li¬ 
brarians  standardize  input  as  recommended  in  the  data 
dictionaries  (Appendices  A  and  C) .  Where  likely  dis¬ 
crepancies  occur,  the  *  symbol  may  be  used  within  a 
word  to  mean  "any  letters,"  or  by  itself  to  mean  "any 
value . " 


B.  INGRES 

Various  other  strengths  and  weaknesses  of  Ingres  were 
learned  during  the  study. 

Ingres  promotes  the  use  of  QBE,  RBF,  and  ABF. in  its  docu¬ 
mentation.  RBF  and  ABF  are  efficient  and  comprehensive  for 
use  for  the  tape  library  and  much  more  complicated  applica¬ 
tions;  QBF  is  not.  When  a  QBF  form  is  called  from  ABF,  at 
least  15  seconds  pass  before  a  form  appears  on  the  screen. 
This  time,  and  the  limitations  on  validations  available,  are 
burdensome  to  the  user.  Input  time  is  faster  tlian  it  would 
be  by  use  of  a  procedure,  but  for  simple  appends  and  updates, 
it  dcsen't  save  enough  time  to  compensate.  REF  takes  a.s  Icn.p 
to  produce  a  report,  which  is  acceptable  considering  the  data 
retrieval,  selection,  and  sorting  process  involved.  ABF  is  a 
powe^rful  and  convenient  tool  for  building  and  *-esting 
a  L 1  ica  t  i  cns  . 


I  no  r  ;■  dcc’ '  me  n  ta  t  ic  n 


i  n  '  int'  1  et  e  . 
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Chapter  IV,  certain  procedures  were  omitted. 


Various  bugs  were  revealed  in  Ingres.  This  was  the 
developers  first  intimate  experience  with  a  commercial  soft¬ 
ware  product.  This  experience  and  discussions  with  more 
experienced  developers  indicates  software,  at  any  price,  is 
always  in  the  test  and  development  stages.  It  is  recommended 
that  the  CS  staff  maintain  close  liaison  with  the  helpful 
hotline  at  RTI  to  improve  the  NPGS  purchase  and  the  RTI 
product . 

C.  REQUIREMENTS  ANALYSIS  AND  DESIGN 

A  requirements  analysis  and  design  process  similar  to 
those  described  by  Kroenke  [Ref.  3]  and  DeMarco  [Ref.  4]  was 
implemented.  Although  there  were  times  when  it  seemed  the 
process  was  in  the  way  of  progress,  it  was  followed  dili¬ 
gently.  As  has  been  written  by  Boehm  [Ref.  5],  and  many 
others,  time  consuming  requirements  result  in  fewer  surprises 
during  the  design  process.  By  the  time  the  design  stage  was 
started,  both  the  library  and  Ingres  were  well  known.  Cnly 
Ingres  bugs  or  deficient  documentation  caused  sirprises 
during  design  and  implementaticn . 


APPENDIX  A 


SPECIFICATION  DATA  DICTIONARY 


A.  DATA  CLASS;  SLOT  (included  in  Tapes)* 


Definition 


A  slot  in  a  tape  cabinet.  Only  one  tape  is 
stored  in  a  slot.  Each  slot  in  a  cabinet  is 
identified  and  labelled  with  an  identification 
number.  Slots  are  labelled  consecutively  left 
to  right,  top  to  bottom 


Elements 


Identification  A  unique  number  assigned  to  a  slot 


Attribute 


Type 


id** 

• 

Type  is  an  attribute  of  tape.  Therefore,  if 
no  tape  is  assigned  to  a  slot,  the  TAPE 
table  will  have  a  null  entry  in  all  tape 
attributes  except  "id". 


If  all  attributes  other  than  "id"  in  table  TAPE  have  null 
values,  the  record  represents  an  empty  slot.  If  the  id 
and  any  other  attributes  in  table  TAPE  have  values,  the 
slot  id  number  is  the  same  as  the  tape  id  number. 


B.  DATA  CLASS:  TAPE 


Definition 


Elements 

Identification 

Attribute 

Constraint 

Length 


Attribute 

Constraint 

Density 


Attribute 

Constraint 

Errors 


Attribute 
Date  of  Errors 
A  t  r  r 1 ou t e 


A  7/9  track  reel  of  magnetic  tape  up  to  3600 
feet  long,  to  be  used  or  being  used  to  store 
data  useful  to  the  CS  department.  Attribute 
values  impact  the  librarian's  decision  of 
whether  or  not  to  use  the  tape  for  a  specific 
"read  to  tape"  request. 


A  unique  identifier  of  a  tape.  The  same  as 
the  identification  number  of  the  slot  to 
which  it  is  assigned 

id 

unique,  key,  mandatory 

The  length  of  the  tape.  Tapes  are  normally 
300,  350,  400,  450,  550,  600,  650,  1200, 
2400,  or  3600  feet  long 

length 

mandatory 

The  bits  per  inch  the  tape  may  copy.  Densi¬ 
ties  are  800,  1600,  6250, a  combination  1600/ 
6250,  or  10,000.  Combinations  shall  be 
recorded  as  6250 

bpi 

mandatory 

The  number  of  bad  bits  on  the  tape.  The 
utility  provides  the  number  when  a  tape  is 
read  or  written.  Used  to  determine  the 
condition  of  the  tape.  If  over  10,  the 
librarian  will  run  it  again  when  the  heads 
are  freshly  changed  to  get  a  more  accurate 
reading.  If  the  figure  remains  greater  than 
10,  it  is  considered  unacceptable  to  use  to 
read  certain  types  of  backups. 

err 


The  date  the  errors  were  last  checked 


aer  r 


C.  DATA  CLASS:  SET 


Definition  A  conceptual  entity  which  is  one  or  more  tapes 
of  recorded  data  (may  be  called  an  active  tape) 
which,  together,  are  identified  as  a  whole. 


Elements 


Type 


Attribute 

Constraints 


System 


Attribute 

Constraints 

Utility 


The  category  of  the  active  tape(s)  by  virtue 
of  what  is  recorded  on  it.  Types  are: 

daily  system  backup  (db) 
weekly  system  backup  (wb) 
monthly  system  backup  (mb) 
graduated  student's  backup  (gb) 
individually  owned-staff  (is) 
individually  owned-facul ty  backup  (if) 
individually  owned-s tudent ^backup  (iu) 
vendor  software  (v) 


type 

key,  mandatory 

if  w  or  v,  value  must  =  db,  wb,  mb,  gb,  is, 

if,  iu,  or  V 

A  code  representing  a  combination  hardware 
and  operating  system  from  which  the  tape  was 
read.  Current  codes  are: 


irisl 

scald2 

iris2 

sunl 

microvaxl 

sun2 

microvax2 

unixl 

Pdpl 

vms  1 

pdp2 

vms2 

scaldl 

system 

key,  mandatory 

The  software  utility  which  was,  and  must  be 
used  to  read  or  write  the  set  of  tapes. 
Utilities  currently  used  by  the  department 
are : 


/Ingres 
/ nps$user 1 
/nps$user2 
/nps$user 3 
/user 


/usrc 
/  V 1  s  1 
/vms  $sys 
'work 
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Attribute  utility 

Constraints  mandatory 

Density  See  "Data  Class:  TAPE" 

Attribute  bpi 

Constraints  must  be  the  same  value  as  Data  Class:  TAPE 

Date  Created  The  date  the  first  bit  of  the  active  set  was 

read  to  tape.  Used  to  determine  the  age  of 
the  bits  and  the  period  of  time  the  tape 
represents.  The  date  to  be  recorded  varies 
according  to  the  type  of  the  set. 

Attribute  dcreate 

Constraints  key,  mandatory 

value  for  each  tape  is  limited  to: 

db,  wb,  mb,  is,  if,  iu  =  date 
read  to  tape 

gb  =  the  date  the  class  graduated 

V  =  the  first  day  of  the  month  the 
tape  was  received  by  the  owner 
or  department 

The  date  the  active  set  should  be  converted 
to  scratch.  (In  the  case  of  individual 
sets,  the  owner's  permission  must  be  obtain¬ 
ed  before  conversion.)  Varying  according  to 
type . 

Attribute  dretire 

Constraints  mandatory 

value  for  each  type  limited  to: 

db  =  dcreate  +  1  month 
wb  =  dcreate  +  3  months 
mb  =  dcreate  +  6  months 
gb  =  dcreate  +  2  years 

V  =  dcreate  +  5  years 
is  =  dcreate  +  2  years 
if  =  dcreate  +  2  years 
iu  =  dcreate  +  2  years 


Retirement 

Date 


I 


Description 


Narrative  com.ments  about  the  set 


Attribute 
Constra int  s 


descr 

none 


Name  of  Owner  The  name  of  the  owner  of  the  tape(s).  Used 

only  in  individual  or  vendor  set  types. 

Attribute  owner 

Constraints  is,  if,  iu  =  mandatory  and  key 
V  =  optiional 
db,  wb,  mb,  gb,  =  null 

Advisor  The  name  of  the  student's  advisor.  Used 

only  in  individual  student  set  type. 

Attribute  advisor 

Constraints  u,  i  =  optional 

db,  wb,  mb,  gb,  is,  if,  v  =  null 

Contact  Phone  A  phone  number.  Only  used  in  individual  or 

vendor  set  types.  The  person  whose  number 
is  recorded  varies  according  to  set  type. 

Attributes  contph 

Constraints  is,  if,  v  =  owner's  phone  number 

iu  =  advisor's  phone  number 

Software  The  name  of  the  software  on  the  tape, 

including  the  version  number.  Only  used 
for  set  type  vendor 

Attribute  software 

Constraints  v  =  mandatory,  key 

db,  wb,  mb,  gb,  is,  if,  iu  =  null 

Vendor  The  name  of  the  vendor  company  which  pro¬ 

duced  the  software.  Used  only  for  set 
type  vendor 

Attribute  vendor 

Constraints  v  =  optional 

db,  wb ,  mb,  gb,  is,  if,  iu  =  null 
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D.  DATA  CLASS:  ACTIVE  TAPE 


Definition  A  conceptual  entity  which  is  one  tape  which,  by 
virtue  of  its  recorded  data  is  a  member  of  a 
set.  Attributes  are  dependent  upon  the  fact  it 
has  recorded  data  and  is  a  member  of  an  active 
set . 

Element 


Identification  A  unique  identifier  of  a  reel,  the  same  as 

the  identification  number  of  the  slot  to 
which  it  is  assigned 


Attribute 

Constraint 

Label 


Attribute 

Constraint 


Sequence 


Attribute 
Cons  traint 


id 

unique,  key,  mandatory 

The  VMS  operating  system  requires  that  each 
tape  be  assigned  a  label  by  the'  librarian. 
When  the  tape  is  mounted,  the  label  verifies 
to  the  system  that  the  tape  is  for  VMS  read/ 
write.  If  the  "copy"  utility  is  used  to 
read  or  write  the  tape,  a  label  must  be 
entered  by  the  librarian  when  mounting  the 
tape.  It  is  not  necessary  for  the  librarian 
to  know  the  label  name  when  using  the  other 
VMS  utility-"backup” .  The  librarian  choses  a 
label  name  which  indicates  what  is  recorded 
on  the  tape . 

label 

if  (utility  =  copy)  mandatory 
if  (utility  =  backup)  optional 

The  sequential  order  of  the  tape  in  the 
total  number  of  tapes  which  make  up  the  set 

seq 

if  number  of  tapes  in  the  parent  set  >  1, 
then  mandatory 


Percent  Used 


At  tr ibute 
Constraint 


The  percent  of  the  tape  which  contained. 

Data  used  for  tapes  which  are  members  of  set 
type  individual  only;  and  only  tape  is 
partially  used. 

perusd 

if  (is.  if,  iu)  and  partially  used,  then 
optional 


E.  DATA  CLASS 

i:  FILE  PATH 

Definition 

A  conceptual  entity  which  provides  the  path  to 
the  disk  location  of  one  or  more  files.  Inher¬ 
ent  in  the  file  path  name  construed  by  the 
librarian  as  the  file  content. 

Elements 

Partition 

A  major  subdivision  of  files  in  the  UNIX 
operating  system.  The  partition  from  which 
the  files  were  read 

Attribute 

part 

Constraint 

if  system  =  UNIX*  then  mandatory,  key 
if  system  =  UNIX*  then  null 

Disk 

A  major  subdivision  by  disk  in  the  VMS  oper¬ 
ating  system.  The  disk  from  which  the  files 
are  read 

Attribute 

disk 

Constraint 

if  system  =  VMS*  then  mandatory,  key 
if  system  =  UNIX**  then  null 

Saveset 

When  using  VMS  "backup"  utility,  marks  the 
beginning  of  each  file  or  set  of  files.  Ter¬ 
minates  with  an  end-of-file  marker.  When 
using  the  "backup"  utility  for  read/write, 
the  saveset  must  be  entered  by  the  librarian 
in  order  to  mount  the  tape.  Librarians 
assign  saveset  names  which  indicate  what  is 
in  the  file 

Attribute 

sav 

Constraint 

if  utility  =  backup  then  mandatory,  key 

Source 

Systems  other  than  VMS  and  utilities  other 
than  backup  and  copy  do  not  require  the 
assignment  of  label  or  saveset  names.  The 
librarian  has  contrived  a  "source"  to  be 
assigned  to  a  file  or  set  of  files  on  a  tape 
which  is  read  by  other  than  VMS  backup  and 
copy  utilities.  The  assigned  name  indicates 
the  file(s)  contents 

Attribute 

src 

Cons  traint 

if  utility  =  backup  or  copy  and 
set  type  =  gb,  then  mandatory 
if  utility  =  backup  or  copy  and 
set  type  =  qb,  then  optional 
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DATA  CLASS 


STUDENT 


Description  The  name  given  to  a  person  who  has  graduated 
from  NPGS  and  whose  files  are  contained  in  a 
set  of  graduation  tapes 


Elements 


Name 

Attribute 

Constraint 

Advisor 

Attribute 

Constraint 

Contact  Phone 

Attribute 


The  last  and  first  name  of  the  student 
name 

required  key 

The  name  of  the  student's  advisor 

advisor 

mandatory 

The  telephone  number  of  the  advisor 
contph 


G.  DATA  CLASS 
Definition 

Element 

Loanee 

Attribute 

Constraint 

Date  Loaned 

Attribute 

Constraint 

Estimated  Date 
of  Return 

Attribute 

Constraint 

Contact  Phone 

Attribute 

Constraint 


;  LOAN 

A  conceptual  entity  which  describes  the 
agreement  under  which  a  tape  is  loaned. 


The  name  of  the  person  to  whom  the  tape  was 
loaned 

loanto 

mandatory  key 

The  date  the  tape  is  loaned 

dloan 

none 

The  date  the  tape  should  be  returned  to  the 
the  library 

edr 

edr  >  dloan 

The  phone  number  of  the  loanee 

Icntph 

none 


rs  1 
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APPENDIX  B 

TABLES  AND  VIEWS 

A.  TABLES  [Ref.  4] 

File,  Loan,  Sets,  Student, 

Tape 

Table : 

File 

Owner: 

Crawford 

Row  Width: 

26 

Saved  Until: 

l-Jan-1999 

00:00:00 

Number  of  Rows: 

21 

Number  of  Pages; 

1 

- 

Journaling; 

disabled 

Storage  Structure: 

heap 

Table  Type: 

user  table 

column  name  type 

length 

column  name 

type 

length 

id  i 

2 

part  disk 

c 

9 

sav  src  c 

15 

err 

i 

1 

Table : 

Loan 

Owner ; 

Crawford 

Row  Width; 

52 

Saved  Until: 

l-Jan-1999 

00:00:00 

Number  of  Rows: 

3 

Number  of  Pages: 

1 

Journaling : 

disabled 

Storage  Structure: 

heap 

Table  Type: 

user  table 

column  name  type 

length 

column  name 

type 

length 

id  i 

2 

d  loan 

date 

12 

ear  date 

12 

loanto 

c 

ionfph  c 

11 
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Table : 

Owner : 

Row  Width: 

Saved  Until: 

Number  of  Rows: 
Number  of  Pages: 
Journaling : 

Storage  Structure: 


Sets 

Crawford 

126 

l-Jan-1999  00:00:00 
12 
1 

disabled 

heap 


Table  Type: 

user  table 

column  name 

type 

length 

column  name 

type 

id 

i 

2 

type 

c 

dcreate 

date 

12 

dretire 

date 

system 

c 

9 

utility 

c 

owner 

c 

9 

advisor 

c 

contph 

c 

4 

software 

c 

vendor 

c 

20 

label 

c 

descr 

c 

15 

sequ 

-f 

perusd 

i 

1 

Table : 

Student 

Owner : 

Crawford 

Row  Width: 

30 

Saved  Until: 

l-Jan-1999 

00:00:00 

Number  of  Rows 

\  2 

4 

Number  of  Pages: 

1 

Journaling: 

disabled 

Storage  Structure: 

heap 

Table  Type: 

user  table 

column  name 

type 

length 

column  name 

type 

id 

i 

2 

name 

c 

advisor 

c 

9 

contph 

c 

length 


lenat  h 
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Table: 

Owner: 

Row  Width: 

Saved  Until: 

Number  of  Rows : 
Number  of  Pages: 
Journaling : 

Storage  Structure: 
Table  Type: 


Tape 

Crawford 

19 

l-Jan-1999  00:00:00 
18 
1 

disabled 

heap 

user  table 


column  name 

type 

length 

column  name 

type 

length 

id 

i 

2 

length 

i 

2 

bpi 

i 

2 

err 

i 

1 

derr 

date 

12 

B.  VIEWS 

vind,  vloan,  vpe,  vretire,  vscloan,  vscratch,  vstudent, 
wen 


VIEW  VIND  DEFINED 


range  of  t  is  tape 
range  of  s  is  sets 
range  of  f  is  file 
define  view  vind  ( 
id  =  s.id, 
type  =  s.type, 
owner  =  s. owner, 
advisor  =  s. advisor 
contph  =  s.contph 
dcreate  =  s.dcreate, 
system  =  s. system, 
utility  =  s. utility, 
bpi  =  t.bpi, 
labe 1  =  s . labe 1 , 
part_disk  =  f.part_disk, 
sav_src  =  f.sav_src, 
descr  =  s.descr, 
err  =  t.err, 
length  =  t. length, 
perusd  =  s.perusd, 
sequ  =  s.sequ) 
where  (s.id  = 


f  .id) 


VIEW  VLOAN  DEFINED 


range  of  t  is  tape 
range  of  s  is  sets 
range  of  1  is  loan 
define  view  vloan  ( 
id  =  t.id, 
type  =  s.type, 
system  =  s. system, 
eequ  =  s.sequ, 
owner  =  s. owner, 
software  =  s. software 
dloan  =  l.dloan, 
loanto  =  l.loanto, 
Icntph  =  l.lcntph, 
edr  =  l.edr) 
where  {t.id  =  s.id) 
and  (l.id  =  t.id) 


VIEW  VPE  DEFINED 


range  of  s  is  sets 
range  of  t  is  tape 
range  of  f  is  file 
define  view  vpe  { 
id  =  s.id, 
type  =  s.type, 
dcreate  =  s.dcreate, 
system  =  s. system, 
utility  =  s. utility, 
bpi  =  t.bpi, 
label  =  s. label, 
part_disk  =  f.part_disk 
sav_src  =  f.sav_src, 
descr  =  s.descr, 
err  =  t.err, 
sequ  =  s.sequ) 
where  (t.id  =  s.id) 
and  (s.id  =  f.id) 
and  (s.type  =  "*b") 


VIEW  VRETIRE  DEFINED 


range  of  t  is  tape 
range  of  s  is  sets 
define  view  vretire  ( 

dretire  =  s.dretire 
type  =  s . type , 
dcreate  =  s.dcreate 
system  =  s. system, 
sequ  =  s.sequ, 
id  =  s.id, 
length  =  t. length, 
bpi  =  t.bpi, 
err  =  t.err) 
where  (t.id  =  s.id) 


VIEW  VSCLOAN  DEFINED 


range 

of  t  is 

tape 

range 

of  s  is 

sets 

range 

of  1  is 

loan 

define 

'  view  vscloan  ( 

id  =  lid. 

edr  = 

1 .edr. 

dloan 

=  1. dloan. 

loanto 

=  1. loanto. 

Icntph 

*  1. Icntph) 

where 

(t.bpi 

!=  0) 

and 

(t. length  !=  0) 

and 

(any (s . 

id  by  t.id 

where 

(t.id  = 

s.id))  = 

and 

(t.id  = 

l.id) 

VIEW  VSCRATCH 

DEFINED 

range  of  t  is  tape 
range  of  s  is  sets 
define  view  vscratch  ( 
id  =  t.id, 
length  =  t. length, 
bpi  =  t.bpi, 
err  =  t.err, 
derr  =  t.derr) 
where  (t.  length  !=  0) 
and  (any (s.id  by  t.id 
where  (t.id  =  s.id))  = 
and  (t.bpi  !=  0) 


VIEW  VSTUDENT  DEFINED 

range  of  t  is  tape 
range  of  s  is  sets 
range  of  rv2  is  student 
range  of  f  is  file 
define  view  vstudent  ( 

name  =  rv2.name, 
dcreate  =  s.dcreate, 
id  =  s.id, 
system  =  s. system, 
utility  =  s. utility, 
bpi  =  t.bpi, 
label  =  s. label, 
part_disk  =  f.part_disk, 
sav_src  =  f.sav_src, 
descr  =  s.descr, 
sequ  =  s.sequ, 
advisor  =  rv2. advisor, 
contph  =  rv2.contph) 
where  (f.id  =  rv2.id) 

and  (s.id  =  f.id) 

and  (t.id  =  s.id) 

and  (s.type  =  "gb") 


VIEW  WEN  DEFINED 

range  of  t  is  tape 
range  of  s  is  sets 
range  of  f  is  file 
define  view  wen  ( 
id  =  s.id, 

software  =  s. software, 
vendor  =  s. vendor, 
system  =  s. system, 
utility  =  s. utility, 
bpi  =  t.bpi, 
label  =  s. label, 
part_disk  =  f.part_disk, 
sav_src  =  f.sav_src, 
descr  =  s.descr, 
owner  =  s. owner, 
advisor  =  s. advisor 
contph  =  s. contph 
err  =  t.err, 
sequ  =  s.sequ) 
where  (s.id  =  f.id) 
and  f t . id  =  s.id) 
and  (s.type  =  "v") 


APPENDIX  C 

DESIGN  DATA  DICTIONARY 

In  Appendix  A,  the  parameters  of  integers  and  floating 
point  numbers  were  expressed  in  bytes,  as  Ingres  does.  The 
parameters  of  these  data  types  are  expressed  in  bits.  Read 
"i2''  as  "integer,  two  digits."  Read  fl.l  as  "one  digit 
decimal  one  digit." 


Field ; 

Name : 

Data  Class: 
Definition: 
Parameters : 
Constraints : 


Storage : 
View: 


advisor 

advisor 

set 

The  name  of  the  student's  advisor. 
c9 

First  eight  letters  of  last  name,  first  initial 
of  first  name;  no  spaces  or  commas. 


Where  Used:  Source  Input:  Table 


Maintenance : 


Other : 


sets,  student 
vstudent 


Table 

Frame 

sets 

student 

1.3.2,  1.3. 3. 2 
1.3.5 

Table 

Frame  Action 

sets 
s  tudent 
sets 

1.4.2  update 
1.5  delete 
1.5  delete 

1.1.3,  1.1 

1.2.4,  1.2 

.4,  1.1.5,  1.2.3, 

.5,  1.2. 8. 2,  1.2.8. 

iri 


Field ; 

Name : 

Data  Class: 
Definition : 
Parameters : 
Constraints : 

Where  Used: 


bpi 

density 

tape 

The  bits  per  inch  capacity  of  the  tape. 
i4 


Valid  values: 
Mandatory 

[800,  1600, 

6250,  10,000] 

Source  Input: 

Table 

Frame 

tape 

1.3.1,  1.3.2 

Maintenance : 

Table 

Frame  Action 

tape 

1.5  delete 

Other : 

1.1.1,  1. 
1.1.5,  1. 
1.2.3,  1. 
1.2. 8.1 

1.2,  l.i;3,  1.1.4, 
1.7,  1.2.1,  1.2.2, 
2.4,  1.2.5,  1.2.7, 

Storage 

View; 


tape 

vind,  vpe,  vretire,  vscratch,  vstudent,  wen 


Field : 

Name : 

Data  Class 


contph 

contact  phone 
set 


Definition:  If  field  advisor  =  null  then  the  phone  number 

of  the  owner 


Parameters : 

If  field  advisor  !=  null 
of  the  advisor 

i4 

then  the 

phone  numbe: 

Constraints : 

Last  four  digits  of  the 
Mandatory 

telephone 

number 

Where  Used: 

Source  Input:  Table 

Frame 

sets 

student 

1.3.2 

1.3.5 

,  1.3. 3. 2 

Maintenance:  Table 

Frame 

Action 

sets 

1.4.2 

update 

student 

1.5 

delete 

Other:  1.1.3,  1.1.4,  1.1.5,  1.2.3, 

1.2.4,  1.2.5,  1.2. 8. 2,  1.2. 8. 4 


Storage 

View: 


sets 

vstudent,  vind 


Field : 

Name : 

Data  Class; 


Definition; 


Parameters ; 
Constraints ; 


Where  Used; 


Storage ; 
View; 


dcreate 
date  created 
set 


If  type  =  db,  wb,  mb,  is,  if,  iu  then  the  date 
the  backup  was  created 

If  type  =  gb  then  the  date  the  class  graduated 
If  type  =  V  then  the  date  the  tape  was  received 
by  NPGS 


mm/dd/yr  (last  two  digits) 
Mandatory 


Source  Input;  Table 


Maintenance ; 


Table 

Frame 

sets 

1.3.2,  1 
1 . 3 . 3  ..2 

.3.3.1, 

Table 

Frame 

Action 

1.4.2 

update 

1.5 

delete 

Other ; 


1.1.2,  1.1.3,  1.1.5,  1.1.7, 

1.2.2,  1.2.3,  1.2.5,  1.2. 8. 2 


sets 

vind,  vpe,  vretire,  vstudent 


Field : 

Name ; 

Data  Class 


derr 

date  of  errors 
tape 


Definition:  The  date  the  errors  were  last  checked. 

Parameters:  c8 

Constraints:  mm/dd/yr  (last  two  digits) 


Where  Used:  Source  Input: 

Table 

Frame 

tape 

1.4.1 

Maintenance : 

Table 

Frame 

Action 

tape 

tape 

1.4.1 

1.5 

update 

delete 

Other : 

1.1.1, 

1.2.1,  1. 2:8.1 

Storage:  tape 

View:  vscratch 


Ay.: 
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UNCLASSIFIED 


F/G  9/2 


NL 


Field : 

Name ; 

Data  Class 


desc 

description 

set 


Definition:  Librarian's  notes  about  the  set. 

Parameters:  cl5 

Constraints:  none 


Where  Used: 

Source  Input: 

Table 

Frame 

sets 

1.3.2,  1 
1.3. 3. 2 

.3.3.1, 

Maintenance : 

Table 

Frame 

Action 

1.4.2 

1.5 

update 

delete 

Other : 

1.1.2,  1.1 

1.2.2,  1.2 

1.2. 8. 2 

.3,  1.1.4, 
.3,  1.2.4, 

1.1.5, 

1.2.5, 

Storage : 
View: 

sets 

vind,  vpe ,  vstudent,  wen 

9  6 


Field;  dretire 

Name;  retirement  date 

Data  Class;  set 

Definition;  If  type  =  db,  wb,  mb,  gb,  is,  if,  iu,  then  the 

date  the  backup  should  be  converted  to 
scratch 

If  type  =  V  then  the  date  the  vendor  tape 
should  be  replaced  due  to  old  bit  age 
If  type  =  is,  if,  iu,  then  permission  must  be 
obtained  from  the  owner  before  conversion 
Recommended  values  by  type; 

db  =  dcreate  +  1  month 

wb  =  dcreate  +  3  months 

mb  =  dcreate  +  6  months 

gb  =  dcreate  +  2  years 

V  =  dcreate  +  5  years 


is,  if. 

iu  =  dcreate 

+  2  years 

Parameters ; 

c8 

Constraints ; 

Mandatory 

Where  Used; 

Source  Input; 

Table 

Module 

sets 

1.3.2,  1.3 
1.3. 3. 2 

.3.1, 

Maintenance ; 

Table 

Module 

Action 

1.4.2 

1.5 

update 

delete 

Other ; 

1.1.7,  1.2. 

7,  1.2. 8. 2 

Storage : 

View: 

sets 

vretire 

.  ^ 


Field; 

Name : 

Data  Class; 
Definition; 


Storage ; 
View; 


edr 

estimated  date  of  return 
loan 

The  date  the  librarian  assigns  for  a  loaned 
tape  to  be  returned  to  the  library. 


Parameters ; 

c8 

Constraints ; 

mm/dd/yr  (last 

two  digits) 

Where  Used; 

Source  Input; 

Table 

Frame 

loan 

1.3.6 

Maintenance ; 

Table 

Frame  Action 

1.4.3  update 

1.5  delete 

Other ; 

1.1. 6.1,  1. 
1.2. 8. 5 

1.6.2,  1.2. 6.1, 

loan 

vloan,  vscloan 


-%  •-  •-  -% 


.  \  -%  _%  *.  V. 


Field; 

Name : 

Data  Class 


Definition: 
Parameters ; 
Constraints ; 
Where  Used; 


err 

errors 

tape 

The  number  of  bad  bits  on  a  tape. 
i2 

1-99 


Source  Input: 

Table 

Frame 

tape 

1.4.1 

Maintenance : 

Table 

Frame 

Action 

tape 

1.4.1 

update 

tape 

1.5 

delete 

Other:  1.1.1,  1.1.2,  1.1. ‘3,  1.1.4, 

1.1.7,  1.2.1,  1.2.2,  1.2.3, 
1.2.4,  1.2.7,  1.2. 8.1 


Storage 

View; 


tape 

vind,  vpe,  vretire,  vscratch,  wen 


Field; 

Name : 

Data  Class; 
Definition; 

Parameters ; 
Constraints ; 

Where  Used; 


id 

identification 

tape 

The  unique  number  assigned  to  all  cabinet  slots 
and  tapes;  key  to  all  tables. 

i5 

1-10000 

Mandatory  input  in  all  tables 


Source  Input; 

Table 

Frame 

tape 

1.3.1,  1 

.3.2, 

sets 

1.3. 3.1, 

1.3. 3. 2 

file 

student 

loan 

1.3. 4.1, 

1.3.5 

1.3.6  . 

1.3. 4. 2 

Maintenance ; 

Table 

Frame 

Action 

sets 

1.5 

delete 

file 

1.5 

delete 

student 

1.5 

delete 

loan 

1.5 

delete 

Other:  1.1.1,  1.1.2,  1.1.3,  1.1.4, 

1.1.5,  1.1. 6.1,  1.1. 6. 2,  1.1.7, 

1.2.1,  1.2.2,  1.2.3,  1.2.4, 

1.2.5,  1.2. 6.1,  1.2. 6. 2,  1.2.7, 

1.2. 8.1,  1.2. 8. 2,  1.2. 8. 3, 

1.2. 8. 4,  1.2. 8. 5,  1.4.1,  1.4.2, 
1.4.3 


Storage : 
Views : 


tape,  sets,  file,  student,  loan 

vind,  vloan,  vpe ,  vretire,  vsclcan,  vscratch 

vstudent,  wen 


Field ; 

Name: 

Data  Class: 
Definition: 


Parameters : 


Storage : 
Views : 


label 

label 

active  tape 

Required  by  the  VMS  operating  system. 

The  name  of  a  tape,  assigned  by  the  librarian 


Constraints:  if  system  =  VMS  then  Mandatory 


Where  Used:  Source  Input:  Table 


Maintenance : 


Other : 


sets 


Table 


Frame 

1.3.2,  1.3. 3.1, 
1.3. 3. 2 


Frame 


Action 


delete 


1.1.2,  1.1.3,  1.1.4,  1.1.5, 

1.2.2,  1.2.4,  1.2.5,  1.2. 8. 2 


sets 

vind,  vpe ,  vstudent,  wen 


Field : 

Name : 

Data  Class 


Icntph 

loanee  contact  phone 
loan 


Description: 

Phone  number 
loaned . 

of  the  person  to  whom  a 

tape  is 

Parameters : 

cll 

Constraints : 

Three  numbers 
numbers  of 
Mandatory 

of  area  code,  space,  seven 
phone  number  (no  hyphen) 

Where  Used: 

Source  Input: 

Table  Frame 

loan  1.3.6 

Maintenance : 

Table  Frame 

Action 

1.4.3- 

1.5 

update 

delete 

Other : 

1.1. 6.1,  1.1. 6.2,  1.2 
1.2. 6. 2,  1.2. 8. 5 

.6.1, 

Storage : 

Views : 

loan 

vloan,  vscloan 

Field; 

Name ; 

Data  Class: 

length 

length 

tape 

Definition: 

The  length  in 

feet  of  a  magnetic  tape. 

Parameters : 

i4 

Constraints ; 

Valid  Value: 

Mandatory 

[300,  400,  450,  555,  600, 
1200,  2400,  or  3600] 

650, 

Where  Used; 

Source  Input: 

Table  Frame 

tape  1.3.1 

Maintenance : 

Table  Frame 

Action 

1.5 

delete 

Other ; 

1.1.1,  1.1.3,  1.1.7,  1 
1.2.3,  1.2.7,  1.2. 8.1 

.2.1, 

Storage ; 

Views : 

tape 

vind,  vretire 

,  vscratch 

Field: 

Name 

Data  Class 


loanto 

loanee 

loan 


Definition; 

Parameters : 
Constraints ; 

Where  Used: 


The  name  of  the  person  to  whom  a  tape  is 
loaned . 

cl5 

Last  name,  comma,  as  much  of  first  name  that 
will  fit 


Mandatory 

Source  Input: 

Table 

Frame 

loan 

1.3.6 

Maintenance : 

Table 

Frame 

Action 

1.4.3 ■ 
1.5 

update 

delete 

Other : 


Storage 
Views ; 


loan 

vloan,  vscloan 


1.1. 6.1,  1.1. 6. 2,  1.2. 6.1 
1.2. 6. 2,  1.2. 8. 5 


Field : 

Name ; 

Data  Class 


name 

name 

student 


Definition : 

Parameters : 
Constraints : 

Where  Used; 


The  name  of  a  student  who  has  graduated  from 
NPGS  and  whose  files  are  maintained  on  a 
graduation  backup  tape. 

cl5 

Last  name,  comma,  as  much  of  first  name  that 
will  fit 
Mandatory 


Source  Input: 

Table 

Frame 

student 

1.3.5 

Maintenance : 

Table 

Frame . 

Action 

1.5 

delete 

Other : 

1.1.5,  1.2 

.5,  1.2. 8. 4 

Storage 

View: 


student 

vstudent 


Field : 

Name : 

Data  Class: 


owner 

owner 

set 


Definition:  The  name  of  owner  of  the  data  on  the  tape. 

Parameters:  c9 


Constraints:  First  eight  letters  of  first  name,  first 

initial  of  last  name;  no  spaces  or  commas 
Mandatory  if  type  =  individual 


Where  Used: 

Source  Input 

:  Table 

Frame 

sets 

1.3.2, 

1.3. 3. 2 

Maintenance : 

Table 

Frame 

Action 

1.4.2 
1.5  ■ 

update 

delete 

Other : 

1.1.3, 

1.2.4, 

1.1.4,  1.1. 
1.2. 6. 2,  1. 

6.2,  1.2.3, 
2.8.2 

Storage : 
Views : 

sets 

vind,  vloan. 

wen 

Field:  part  disk 

Name:  partTtion  or  disk 

Data  Class:  file  path 

Description:  Partition  is  a  major  subdivision  of  files  in 

the  UNIX  operating  system.  Disk  is  a  major 
subdivision  of  files  by  disk  in  the  VMS 
operating  system. 


Parameters : 

c9 

Constraints : 

Mandatory 

Where  Used: 

Source  Input: 

Table  Frame 

file  1.3.2,  1 

1.3. 4. 2 

.3.4.1, 

Maintenance 

Table  Frame 

Action 

1.5 

delete 

Other ; 

1.1.2,  1.1.3,  1.1.4, 

1.2.2,  1.2.3,  1.2.4, 
1.2. 8. 3 

1.1.5, 

1.2.5, 

Storage : 
Views :' 


file 

vind,  vpe,  vstudent,  wen 


Field: 

Name : 

Data  Class: 
Definition: 

Parameters : 
Constraints : 
Where  Used 


perusd 

percent  used 
active  tape 


If  type  =  is,  if,  or  lu  then  the  percent  used 
of  the  last  tape  of  a  sequence  of  tapes  which 


make  up  a  set.  Use  only 
than  100. 

i2 

1-99 

Source  Input:  Table 

sets 

Maintenance:  Table 


if  percent  is  less 


Frame 

1.3. 3. 2,  1.3. 4. 2 
Frame  Action 

1.5  ’  delete 


Other : 


1.1.3,  1.2.3,  1.2. 8. 2 


Storage 


sets 


Field; 

Name ; 

Data  Class 


Definition: 

Parameters ; 
Constraints : 
Where  Used; 


Storage ; 
Views ; 


sav_src 

savset  or  source 
file  path 

If  VMS  backup  utility  then  marker  for  beginning 
of  each  set  of  files. 

If  not  VMS  backup  utility,  then  librarians  name 
of  a  set  of  files 

cl5 


Mandatory 


Source  Input; 

Table 

Frame 

file 

1.3.2,  1 
1.3. 4. 2 

.3.4.1, 

Maintenance : 

Table 

Frame 

Action 

1.5 

delete 

Other : 

1.1.2,  1.1 
1.2.2,  1.2 
1.2. 8.3 

.3,  1.1.4, 

. 3 ,  1.2.4, 

1.1.5, 

1.2.5, 

file 

vind,  vpe,  vstudent,  wen 


Field ; 

Name : 

Data  Class 


sequ 

sequence 
active  tape 


Definition;  The  sequential  number  of  a  tape  in  the  total 


number  of  tapes  which  make 
as  "one  of  four") . 

up  a  set 

(read  "1.4 

Parameters : 

fl.l 

Constraints : 

Express  as  sequence  number 
number  (e.g.  1.4) 

decimal 

point  total 

Where  Used; 

Source  Input:  Table 

Frame 

sets 

1.3. 3.1 

,  1.3. 3. 2 

Maintenance:  Table 

Frame 

Action 

1.4.2 

1.5 

update 

delete 

Storage; 
Views ; 


Other:  .  1.1.2,  1.1.3,  1.1.4,  1.1.5, 

1.1. 6. 2,  1.1.7,  1.2.2,  1.2.3, 
1.2.4,  1.2.5,  1.2. 6. 2,  1.2.7, 

1.2. 8. 2,  1.3.2 

sets 

vind,  vloan,  vpe,  vretire,  vstudent,  wen 
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Field:  software 

Name:  software 

Data  Class:  sets 

Definition:  The  name  of  the  software  of  a  vendor  tape. 

Parameters:  cl5 

Constraints:  Include  version  number  after  name.  If  the  name 

is  too  long  leave  off  enough  letters  to  include 
version  number  as  last  entry. 

Mandatory 


Where  Used:  Source  Input: 

Table 

Frame 

sets 

1.3.2 

Maintenance : 

Table 

Frame 

Action 

1.5 

delete 

Other ; 

1.1.4, 

1.1. 6. 2,  1.2.4, 

1.2. 6. 2 

1.2. 8. 2 

Storage:  sets 

Views:  vloan,  wen 


Field: 

Name : 

Data  Class: 
Definition: 
Parameters : 
Constraints : 


Where  Used: 


system 

system 

set 


Combination  hardware  and  operating  system  code 
c9 


Valid  Values: 

irisl 

nbi3 

pdpl 

iris2 

nbi4 

pdp2 

microvaxl 

nbiS 

unixl 

microvax2 

nbi6 

vmsl 

nbil 

nbi7 

vms2 

nbi2 

nbi8 

Mandatory 

Source  Input: 

Table 

Frame 

sets 

1.3.2,-  1.3 
1.3. 3. 2 

.3.1, 

Maintenance : 

Table 

Frame 

Action 

1.5 

delete 

Other: 

1.1.2,  1.1. 

3,  1.1.4,  1 

.1.5, 

1.1. 6. 2,  1. 

1.7,  1.2.2, 

1.2.3, 

1.2.4,  1.2. 
1.2. 8. 2 

5,  1.2. 6. 2, 

1.2.7, 

Storage 
Views : 


sets 

vind,  vloan,  vpe,  vretire,  vstudent,  wen 


Field; 

Name : 

Data  Class; 

type 

type 

set 

Definition; 

The  category  of 
is  recorded  on 

active 

it. 

tape 

by  virtue  of  what 

Parameter ; 

c2 

Constraints ; 

db ,  wb ,  mb ,  gb , 
Mandatory 

is,  if. 

iu. 

V 

Where  Used; 

Source  Input; 

Table 

Frame 

sets 

1.3.2,  1.3. 3.1, 
1.3. 3. 2 

Maintenance ; 

Table 

Frame  Action 

1.5  ■  delete 

Other ; 

1.1.2, 
1.2.2, 
1.2. 8. 2 

1.1. 

1.2. 

3,  1.1. 6. 2,  1.1.7, 
3,  1.2. 6. 2,  1.2.7, 

storage 
Views : 


sets 

vind,  vloan,  vpe,  vretire 


Field: 

Name : 

Data  Class: 


utility 

utility 

set 


Definition: 

The  software  utility  used 
backup  or  vendor  tape. 

to  read  or 

write  the 

/ingres 

/nps$userl 

/nps$user2 

/nps$user3 

/user 

/  usrc 
/vlsl 

/vms$sys 

/work 

Parameters : 

c6 

' 

Constraints : 

Mandatory 

Where  Used: 

Source  Input: 

Table 

Frame 

sets 

1.3.2,  1. 
1.3. 3.2 

3.3.1, 

Maintenance : 

Table 

Frame 

Action 

1.5 

delete 

Other : 

1.1.2,  1.1 

1.2.2,  1.2 

1.2. 8. 2 

.3,  1.1.4, 
.3,  1.2.4, 

1.1.5  , 
1.2.5, 

Storage:  sets 

Views:  vind,  vpe ,  vstudent,  wen 
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Field: 

Name : 

Data  Class 


vendor 

vendor 

set 


Definition: 
Parameter : 
Constraints : 
Where  Used: 


Storage : 
View: 


The  name  of  the  vendor  of  a  vendor  tape. 
c20 

Mandatory 


Source  Input: 

Table 

Frame 

sets 

1.3.2 

Maintenance : 

Table 

Frame 

Action 

1.5 

delete 

Other : 

1.1.4, 

1.2.4,  1.2. 8. 2 

sets 

wen 


1.1 

MENU:  TQuery/Report  (terminal) 

FRAME :  tquery 

USAGE:  user 

FORM:  tquery 


QUERY/REPORT  TO  TERMINAL 


scratch 

periodic  (db,  wb,  mb,  gb) 

individual  (is,  if,  iu) 

vendor 

student 

loaned 

date  to  retire 

return 

exit 


SCRATCH  PER  IND  VEN  STU  LOAN  DATE  RETURN  EXIT: 


PROCEDURE:  tquery. osl 

scratch  =  Ccallframe  rscratch; } 
per  =  Ccallframe  rpe;) 
ind  =  Ccallframe  rind;} 
ven  =  Ccallframe  rvendor; } 
stu  =  Ccallframe  rstudent;} 
loan  =  Ccallframe  reploan;} 
date  =  Ccallframe  rdate; } 
return  =  Creturn;} 
exit  =  Cexit;} 


1.1.1 

MENU:  scratch 

FRAME:  rscratch 

USAGE:  report 

FORM:  rscratchf 


Field  Attributes:  Mandatory  -  max  length 


REPORT:  rscratch 


Report  Definition;  Sort  by  length,  bpi ,  errors,  id 

Select  length  by  range  at  runtime 
Output  to  terminal 
Command  flag  -  L80 


TABLE:  rscratch 


1.1.2 

MENU:  Periodic 

FRAME :  rpe 

USAGE:  report 

FORM:  rperf 


Field  Attributes: 

Mandatory  -  type,  system,  max_dcreat,  part_ 

dick,  sav_src  (type  =  db,  wb,  mb, 
gb,  or  *  only) 

Validation-  type  in  [db,  wb,  mb,  gb,  *] 
system  (refer  to  Appendix  C) 

*  selects  "all” 


REPORT:  rper 


Report  Definition:  Sort  by  type,  dcreate,  system, 

part_disk,  sequ,  sav_src 
Select  dcreate  by  range  at  runtime 
Select  type,  system,  part_disk, 
sav_src  by  value  at  runtime 
Output  to  terminal 
Command  Flag  -  L80 


1 

MENU : 
FRAME : 
USAGE: 
FORM  ; 


Individual 

rind 

report 

rindf 


Report  Definition:  Sort  by  type,  owner,  dcreate, 

system,  sequence 
Select  type,  owner,  system, 

part  disk,  sav_src  by  value  at 
runtTme 

Output  to  terminal 
Command  flag  -  L80 


TABLE : 


V  mu 


1.1.4 

MENU:  Vendor 

FRAME:  rvendor 

USAGE:  report 

FORM:  rvendorf 


ENTER  PARAMETERS  FOR  VENDOR  REPORT 

Table  is:  wen 

software : 

system: 

vendor : 

HELP  REPORT 

RETURN 

Field 

Attributes : 

Mandatory  -  software,  vendor,  system 
Validation-  system  (Appendix  C)  *  selects  all 

REPORT:  rvendor 

ll-SEP-1985 

REPORT  ON  VENDOR 
Report  on  Table: 

12:48:35 

TAPES 

wen 

software: 
vendor : 
system: 
owner : 
id:  (i5) 
sequ:  (f4.1) 

part  disk: 
sav  ¥rc: 
descr : 
advisor : 
contph: 

utility: 

1 abe 1 ; 
bpi:  (i5) 
err:  (i2) 

Report  Definition:  Sort  by  software,  vendor,  system, 

owner,  sequ 

Select  software,  vendor,  system, 
by  value  by  runtime 
Output  to  terminal 
Command  flag  -  L80 


TPiBLE :  wen 
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1.1.5 
MENU: 
FRAME : 
USAGE : 
FORM: 


Student 

rstudent 

report 

rstudentf 


ENTER 

PARAMETERS  FOR  STUDENT  REPORT 
Table  is:  vstudent 

min  dcreate: 

max_dcreate 

name : 

system: 

HELP  REPORT  RETURN: 

Field  Attributes: 

Mandatory  -  max_dcreate ,  name,  system 
Validation-  System  (Appendix  C)  *selects  all 


REPORT:  rstudent 


Il-SEP-1985 


REPORT  ON  STUDENT  TAPES 
Report  on  Table:  vstudent 


dcreate:  (mm/dd/yr) 
name : 

sequ:  (fl.l) 
id:  (i5) 


system: 
part__diski 
sav_src: 
descr : 


10:37:26 


label : 
utility: 
bpi ;  (i5) 

advisor ; 
contph ; 


Report  Definition:  Sort  by  dcreate,  name,  system, 

part_disk,  sequ,  sav_src 
Select  dcreate  by  range  at 
runtime 

Select  name,  system  by  value  at 
runtime 

Output  to  terminal 
Command  flag  -  L80 


'•'-■-'"-■■'I-'’ 


1.1. 6.1 

MENU:  Scratch 

FRAME:  Inscratch 

USAGE:  report 

FORM:  default  blank 


TABLE:  vscloan 


1.1. 

MENU: 
FRAME : 
USAGE: 
FORM: 


Backup  or  Vendor 

r  loan 

report 

rloanf 


ENTER  PARAMETERS  FOR  LOANED  TAPES  REPORT 
Table  is:  vloan 


min  edr: 


max  edr: 


loanto : 


HELP  REPORT  RETURN: 


Field  Attributes: 

Mandatory  -  max  edr,  loanto 


REPORT:  rloan 


ll-SEP-1985 


10:40:26 


REPORT  ON  LOANED  BACKUP  AND  VENDOR  TAPES 
Report  on  Table:  vloan 


id:  (i5)  loanto: 
edr:  (mm/dd/yr)  Icntph: 
dlcan:  (mm/dd/yr)  owner: 


type : 
software : 
system : 
sequ :  ( f  4 . 1 i 


Report  Definition:  Sort  by  id 

Select  -  edr  by  range  at  runtime 
loanto  by  value  at 
runtime 

Output  file  -  terminal 
Command  flag  -  L80 


TAHLE 


^  *_.»•  Tj* 


1.1.7 

MENU: 

Date  to  Retire 

FRAME : 

rdate 

USAGE: 

report 

FORM: 

rdatef 

ENTER 

PARAMETERS  FOR  RETIREMENT 

DATE  REPORT 

Table  is:  vretire 

min  dretire: 

max  dretire 

type : 

HELP  REPORT 

RETURN: 

Field  Attributes: 

Mandatory  -  max  dretire,  type 


REPORT:  rdatef 


ll-SEP-1985 

12:50:55 

REPORT 

ON  RETIREMENT 

DATES 

Report 

on  Table:  vretire 

dretire;  (mm/dd/yr) 

type : 

length:  (i4) 

dcreate;  (mm/dd/yr) 

system: 

bpi;  (i5) 

id ;  ( i5 ) 

sequ:  (f4.1) 

err;  (i2) 

Report  Definition:  Sort  by  dretire,  type,  dcreate, 

system,  sequ 

Select  dretire  by  range  at 
runtime 

Select  type  by  value  at  runtime 
Output  file  -  terminal 
Command  flag  -  L80 


i 

■r- * , 

1.2.1 

MENU; 

Scratch 

FRAME ; 

pscratch 

9 

USAGE ; 

report 

FORM; 

pscratchf 

ENTER  SCRATCH  REPORT  PARAMETERS 

min  length; 

max  length; 

outputs  to  file;  pscratch 

HELP  REPORT 

RETURN; 

Field  Attributes;  Mandatory  -  max  length 


REPORT;  pscratch 


ll-SEP-1985 

10:41:35 

REPORT 

ON  SCRATCH  TAPES 

Report  on 

Table ; 

vscratch 

id  length 

bpi 

err 

derr 

(15)  (i4) 

(i5) 

(12) 

(mm/dd/yr ) 

Report  Definition;  Sort  by  length,  bpi ,  err,  id 

Select  length  by  range  at  runtime 
Output  file  -  pscratch 
command  flag  -  L132 


TABLE;  vscratch 


1.2.2 

MENU;  Periodic 
FRAME;  pperiodic 
USAGE;  report 
FORM:  pperf 


ENTER  PARAMETERS  FOR  PERIODIC  BACKUP  REPORT 

Table  is: 

vpe 

type ; 

system: 

min  dcreate; 

max  dcreate: 

part  disk: 

sav  src: 

outputs  to  file: 

periodic 

HELP  REPORT  RETURN: 

Field  Attributes: 

Mandatory  -  type,  system,  max_dcreate, 
part_disk,  sav_src 

Validation-  type  =  db,  wb,  mb,  gb,  * 

System  (Appendix  C)  *  selects  all 


REPORT;  ppe 


ll-SEP-1985 

. 

10:42:53 

REPORT  ON  PERIODIC  BACKUP  TAPES 

Report 

on  Table:  vpe 

id:  (i5) 

type : 

dcreate;  (mm/dd/yr) 

system : 

utility; 

label : 

bpi:  (i5) 

err:  (i2) 

part  disk: 

sav  src; 

sequ :  ( f  4 . 1 ) 

descr ; 

Report  Definition:  Sort  by  type,  dcreate,  system, 

part_disk,  sequ,  sav_src 
Select  type,  system,  part_disk, 
sav_src  by  value  at  runtime 
Select  dcreate  by  range  at  runtime 
Output  to  file  -  pperiodic 
Command  Flag  -  L132 


TABLE : 


vce 
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1 

MENU  : 
FRAME : 
USAGE : 
FORM 


Individual 
pindividual 
report 
Dindf 


ENTER  INDIVIDUAL  BACKUP  REPORT  PARAMETERS 


type : 

part  disk: 


system: 


outputs  to  file:  pindividual 


owner: 


sav  src 


HELP  REPORT  RETURN: 


Field  Attributes 


Mandatory  -  type,  owner,  system 

part_disk,  sav-src 

(type  =  is,  if,  iu,  or  *  only) 


REPORT:  pind 


ll-SEP-1985 

REPORT 

ON  INDIVIDUAL  BACKUPS 
Table  is;  vind 

12:45:08 

type; 
owner : 

dcreate : 

(mm/dd/yr ) 

system: 
sequ:  (fl.l) 
id:  (iS) 

part  disk: 
sav  src: 

descr : 

utility; 
label : 
bpi:  (i5) 

length;  (i4) 
perusd:  (i2) 
err;  (i2) 

advisor:  I 

contph : 

Report  Definition;  Sort  by  type,  owner,  dcreate, 

system,  sequ 

Select  type,  owner,  system, 
part_disk,  sav_src  by  value 
Output  to  file  -  pindividual 
Command  flag  -  LI 3 2 


TABLE: 


vind 


•  f 


1.2 
MENU: 
FRAME : 
USAGE: 
FORM: 


Vendor 
pvendor 
report 
pvendorf 


Field  Attributes: 

Mandatory  -  software,  vendor,  system 
Validation-  system  (Appendix  C)  *  selects  all 


REPORT:  pvendor 


ll-SEP-1985 


11:53:22 


REPORT  ON  VENDOR  TAPES 
Report  on  Table:  wen 


software:  system:  part_disk:  utility;  err;  (i2) 

vendor;  sequ:  (f4.1)  sav_src;  label:  advisor: 

owner:  id:  (i5)  descr;  bpi :  (i5)  contph: 


Report  Definition;  Sort  by  software,  vendor,  system 

owner,  sequ 

Select  software,  vendor,  system 
by  value  at  runtime 
Output  to  file  -  pvendor 
Command  flag  -  L132 


TABLE : 


wen 


1.2.5 

MENU: 

Student 

FRAME : 

pstudent 

USAGE : 

report 

FORM: 

pstudf 

ENTER  PARAMETERS  FOR  STUDENT  REPORT 
Table  is:  vstudent 


min_dcreate : 
name : 


max_dcreate ; 
system: 


outputs  to  file:  pstudent 


HELP  REPORT  RUN 


Field  Attributes: 

Mandatory  -  max_dcreate,  name,  system 
Validation-  system  (Appendix  C)  *  selects  all 


REPORT:  pstud 


1.2.6 

MENU: 

Loaned 

FRAME : 

prloan 

USAGE: 

user 

FORM: 

reploan 

SELECT  TYPE  OF  LOANED  TAPES  TO  REPORT 

scratch 

backup  or  vendor 

return 

exit 

SCRATCH  BACK  RETURN  EXIT: 


PROCEDURE:  prloan.osl 

scratch  =  [callframe  plnscratch; 3 
back  =  Ccallfraine  ploan;3 
return  =  (return;} 
exit  =  (exit;} 


1 

MENU 
PRAM 
USAG 
FORM 


outputs  to  file:  pinscratch 


HELP  REPORT  RETURN: 


ll-SEP-1985 

11:08:19 

REPORT  ON  LOANED  SCRATCH  TAPES 

Report  on  Table; 

vscloan 

loanto:  Icntph:  edr: 

dloan: 

id:  (i5) 

(mm/dd/yr ) 

(mm/dd/yr) 

Sort  by  name 
Output  to  fi 
Command  flag 


1 

MENU: 
FRAME ; 
USAGE : 
FORM: 


Backup  or  Vendor 

ploan 

report 

ploanf 


ENTER 

PARAMETERS  FOR  LOANED  TAPES  REPORT 

Table  is:  vloan 

min_ 

edr : 

max  edr : 

loanto : 

outputs  to  file:  ploan 

HELP 

REPORT 

RETURN: 

Field  Attributes:  Mandatory  -  max  edr ,  loanto 


REPORT:  ploan 


ll-SEP-1985 

11:10:04 

REPORT 

ON  LOANED  BACKUP  AND  VENDOR  TAPES 

Report  on  Table:  vloan 

loanto : 

edr:  (mm/dd/yr)  dloan:  (mm/dd/yr) 

id:  (i5) 

Icntpl • 

type : 

owner:  system:  1 

software : 

sequ :  ( f  4 . 1 )  | 

1 

Report  Definition:  Sort  by  name,  edr,  id 

Select  edr  by  range  at  runtime 
Select  loanto  by  value  at  runtime 
Output  to  file  -  ploan 
Command  flag  -  L132 


TABLE:  vloan 


1.2.7 
MENU  ; 
FRAME : 
USAGE: 
FORM: 


Date  to  Retire 
pdate 
report 
pdatef 


ENTER  PARAMETERS  FOR  RETIREMENT  DATE  REPORT 
Table  is:  vretire 


min  dretire: 


max  dretire: 


type : 


outputs  to  file:  pretire 


HELP  REPORT  RETURN: 


Field  Attributes:  Mandatory  -  max  dretire,  type 


«2iCI 


REPORT:  pdate 


ll-SEP-1985 


10:47:51 


REPORT  ON  RETIREMENT  DATES 
Report  on  Table:  vretire 


dretire:  (mm/dd/yr) 
id:  (i5) 


type : 


system: 


sequ : 
:f4.1) 


length ; 
(i4) 


dcreate:  (mm/dd/yr) 


bpi : 
[i5) 


Report  Definition:  Sort  by  dretire,  type,  dcreate, 

system,  sequ 

Select  dretire  by  range  at 
runtime 

Select  type  by  value  at  runtime 
Output  to  file  -  pretire 
Command  flag  -  L132 


TABLE:  vretire 


SELECT  TABLE  FOR  DUMP  REPORT 


tape 

sets 

file 

student 

loan 

return 

exit 

TAPE  SETS  FILE  STU  LOAN  RETURN  EXIT: 


PROCEDURE;  pdump.osl 

tape  =  Ccallframe  tape;) 
sets  =  Ccallframe  sets;) 
file  =  Ccallframe  file;) 
stu  =  Ccallframe  student;) 
loan  =  Ccallframe  lean;) 
return  =  Creturn;) 
exit  =  Cexit ; ) 


144 


outputs  to  file 


HELP  REPORT  RETURN: 


REPORT:  tape 


ll-SEP-1985 


DUMP  ■ 

Report  on  Table:  tape 


10:49 


id  length  bpi  err  derr 

(i5)  (i4)  (i5)  (i2)  (mm/dd/yr) 


Report  Definition:  Sort  by  id 

Output  to  file  -  dtape 
Command  flag  -  L80 


TABLE:  tape 
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ll-SEP-i985 


DUMP 

Report  on  Table;  file 


part  disk 


sav  src 


11:10:49 


iH 


Report  Definition:  Sort  by  id 

Output  to  file  -  dfile 
Command  flag  -  L132 


TABLE:  file 


..  \  ’C".  •_*,  is_‘ .  •%.*  pfJ\ 


1.2. 8. 4 

MENU:  Student 

FRAME:  student 

USAGE:  report 

FORM:  student 


outputs 

to  file: 

dstudent 

! 

HELP  REPORT  RETURN: 

REPORT:  student 

ll-SEP-1985 

DUMP 

10:51:51 

Report 

on  Table: 

student 

1 

id  name 

(i5) 

advisor 

contph 

Report  Definition:  Sort  by  id 

Output  to  file  -  dstudent 
Command  flag  -  L80 


TABLE:  student 


148 


MtJ’i  M_".  A_'.  A_''.  A_'.  ■ 


1.2. 8. 5 
MENU;  Loan 
FRAME:  loan 

USAGE;  report 
FORM:  loan 


outputs  to  file: 

dloan 

HELP 

REPORT  RETURN; 

REPORT ; 

loan 

11-SEP 

-1985 

DUMP 

Report  on  Table: 

loan 

10:52:33 

id 

(i5) 

dloan  edr 

(mm/dd/yr)  (mm/dd/yr) 

loanto 

Icntph 

Report  Definition;  Sort  by 

Output 

Command 

id 

to  file 
flag  - 

-  dloan 

L132 

TABLE:  loan 


1.3 
MENU 
FRAME 
USAGE 
RM 


SELECT  ADD 


scratch 


vendor 


backup 


files 


students 


loan 


return 


SCRATCH  VENDOR  BACKUP  FILES  STUDENTS  LOAN  RETURN 


PROCEDURE;  tadd.osl 


scratch  =  Ccallframe  ascratch;} 
vendor  =  Ccallframe  avendor;} 
backup  =  Ccallframe  abackup; ) 
files  =  Ccallframe  aafiles;} 
students  =  Ccallframe  astudents;} 
loan  =  Ccallframe  aloan;} 
return  =  Creturn;) 


15  0 


ADD  SCRATCH  TAPES 
Table  is:  tape 

id:  length:  bpi: 

select  id;  enter  data,  add 

ID  ADD  RETURN: 


Field  Attributes: 

Display  only  -  id 

Repeat  values  for  -  length,  bpi 

Mandatory  -  length,  bpi 

Validation  -  length,  bpi  (Appendix  C) 


PROCEDURE  (1) :  ascratch.osl 


id  =  [callproc  sgetid;] 
add  =  Ccallproc  ascratchc;} 
return  =  [return;} 


1.3.1  (Continued) 


PROCEDURE  (2):  sgetid.qc 

sgetid ( ) 

C 

##  int  low; 

##  int  top; 

##  int  new; 

int  i ; 

i=low=0 ; 

##  retrieve  ( low=min (tape.id  *retrieve  an  empty  slot 

##  where  ( tape . length=0  and  with  the  lowest  id 

##  { tape .bpi=0) ) ) 

##  C 

i=i+l; 

##  ] 

if  (low!=0)  *if  an  empty  slot  exists 

C 

##  putform  anoscratch  (id=low)  *put  the  id  on  the  form 

##  message  "OLD  ID" 

##  sleep  2 

##  return; 

] 

else  *if  no  empth  slots  exist 

f 

##  retrieve  ( top=max ( tape . id) ) 

##  C 

i  +  +; 

##  } 

if  (top>0) 

( 

new=l+top;  *increment  the  max  id 

assigned  by  one 

##  putform  anoscratch  *put  the  new  id  number 

##  (id=new)  on  the  form 

##  message  "NEW  ID" 

##  sleep  2 

return; 


1.3.1  (Continued) 


PROCEDURE  (3) ;  ascratchc.qc 
ascratchc ( ) 


f 


## 

int  nu; 

## 

int  le; 

## 

int  b; 

## 

int  check; 

int  i; 

i=check=0 ; 

## 

getform  anoscratch (nu=id , 

*get  the  values  from  the 

## 

le=length,  b=bpi) 
if  (nu==0) 
i 

message  "Select  ID  before 

form 

## 

*if  the  user  tried  to 

## 

entering  data" 

enter  data  prior  to 
getting  an  id 

## 

sleep  2 
return; 

} 

retrieve  (check=tape . id) 

## 

*find  a  record  of  an 

## 

where  tape.id=nu 

empty  slot  with  the  id 

## 

C 

i  +  + ; 

number 

## 

3 

if  (check>0) 

*if  an  empty  slot  of  the 

C 

id  number  exists 

## 

replace  tape 

♦update  the  record  of 

## 

(length=le,  bpi=b) 

the  empty  slot  in  the 

## 

where  tape.id=nu 

tape  table 

## 

message  "Added  to  old 

## 

ID;  label  tape  only" 

## 

sleep  2 

## 

putform  anoscratch 

## 

(id=0) 

return; 

3 

else 

*if  the  id  is  not  in  the 

[ 

tape  table 

## 

append  to  tape 

♦append  to  tape  table 

## 

( 

## 

id=nu , 

## 

length= le , 

1.3.1  (Concluded) 


##  message  "Added  to  new 

##  ID,  label  slot  and  tape" 

##  sleep  2 

##  putform  anoscratch  *to  prevent  double  entry 

##  (id=0) 

] 

} 


TABLE:  tape,  sets 


ADD  VENDOR  TAPES 
Tables  are  Tape  and  Sets 


id :  type : 

system; 

owner : 

software : 

descr : 


dcreate;  dretire: 

utility:  label;  bpi : 

advisor;  contph; 

vendor : 

sequ: 


select  id;  enter  data;  add 


ID  ADD  RETURN: 


Field  Attributes; 

Display  only  -  id,  type 
Repeat  values  for  all  except  id 
Mandatory  -  dcreate,  dretire,  system,  utility, 
bpi,  software,  vendor 

Validation  -  system  (Appendix  C)  *  selects  all, 
bpi  (Appendix  C) 


PROCEDURE  (1);  avendor.osl 

id  =  Ccallproc  vgetid;] 
add  =  (callproc  avendorc;} 
return  =  (return; } 


1.3.2  (Continued) 


PROCEDURE  (2);  vgetid.qc 
vgetid ( ) 


C 


## 

int  low; 

## 

int  top; 

## 

int  new; 

int  i ; 

i=low=0 ; 

## 

retrieve  (low=min (tape.id 

♦retrieve  an  empty  slot 

## 

where  (tape.length=0)  and 

with  the  lowest  id 

## 

(tape.bpi=0) ) ) 

## 

C 

i  =  i  + 1 ; 

## 

3 

if  (low!=0) 

[ 

putform  advendor 

*if  an  empty  slot  exists 

## 

♦put  id  and  type  on  the 

## 

(id=low,  type  =”v") 

form 

## 

message  "OLD  ID" 

## 

sleep  2 
return; 

3 

else 

C 

retrieve  (top=max 

♦if  no  empty  slots  exist 

## 

## 

(tape. id) ) 

## 

{ 

i  +  + ; 

## 

3 

if  (top>0) 

C 

♦increment  the  max  id  by 

new=l+top; 

one 

## 

putform  advendor 

♦put  the  new  id  and  type 

## 

(id=new,  type="v") 

on  the  form 

## 

message  "NEW  ID" 

## 

sleep  2 
return ; 

3 

} 

3 


TABLE:  tape,  vendor 
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1.3.2  (Continued) 

PROCEDURE  (3) :  avendorc.qc 

avendorc .qc ( ) 

C 


## 

int 

nu; 

## 

char 

ty[2]  ; 

## 

char 

da [26]  ; 

## 

char 

dr[26]  ; 

«« 

char 

sy [9]  ; 

## 

char 

ut  [  6  [  ; 

## 

char 

ow[9]  ; 

## 

char 

CO [4]  ; 

## 

char 

so[15]  ; 

## 

char 

ve  [  2  0  ]  ; 

## 

char 

la[6]  ; 

## 

float 

se; 

## 

int 

b; 

## 

char 

de[15]  ; 

## 

char 

ad  [9]  ; 

## 

int 

check; 

int  i ; 

##  getform  advendor  (nu=id,  *get  the  values  from  the 

##  ty=type,  da=dcreate,  form 

##  dr=dretire,  sy=system, 

##  ut=utility,  ow=owner, 

##  co=contph,  so=software, 

##  ve=vendor,  la=label,  se*sequ, 

##  b=bpi,  de=descr,  ad=advisor) 

if  (nu==0) 

C 

##  message  "Select  id  before 

##  selecting  add" 

##  sleep  2 

return; 

] 

i=check=0 ; 

##  retrieve  (check=tape . id) 

##  where  tape.id=nu 

##  C 

i  +  + ; 

##  3 

if (check  >  0 ) 

C 

8#  replace  tape  (bpi=b)  where 
tape.id=nu 


*if  the  user  tried  to 
enter  data  prior  to 
getting  an  id 


*find  a  record  of  the 
empty  slot  with  the  id 
number 

*if  an  empth  slot  of  the 
id  number  exists 
*update  the  record  of 
the  empty  slot  in  the 
tace  table 


1.3.2  (Concluded) 


##  append  to  sets{id=nu,  type=ty, 

##  dcreate=da,  dretire=dr, 

##  system=sy,  utility=ut,  owner=ow, 

##  contph=co,  software=so,  vendor=ve, 

##  label=la,  sequ=se,  descr=de, 

##  advisor=ad) 

##  message  "Added  to  old  ID; 

##  label  tape  only" 

##  sleep  2 

##  putform  advendor  (id=0) 

return; 

3 

else  *if  the  id  is  not  in  the 

C  tape  table 

##  append  to  tape (  *append  to  the  tape 

##  id=nu,  bpi=b  table 

##  ) 

##  append  to  sets(id=nu,  type=ty, 

##  dcreate=da,  dretire=dr, 

##  system=sy,  utility=ut,  owner=ow, 

##  contph=co,  software,  so,  vendor=ve, 

##  label=la,  sequ=se,  descr=de, 

##  advisor=ad) 

##  message  "Added  to  new  ID; 

##  label  slot  and  tape" 

##  sleep  2 

##  putform  advendor (id=0)  *to  prevent  double  entry 

3 
3 


TABLE:  tape,  set 


1.3. 3.1 

MENU:  Periodic  (db,  wb,  mb,  gb) 

FRAME:  aperiodic 

USAGE:  QBF-append 

FORM:  aperiod 


ADD  ID  AND  BACKUP  DATA  FOR  EACH  ID  IN  SET 
Table  is:  sets 


label:  sequ: 

dcreate:  dretire: 

system:  utility: 

descr : 


APPEND  #1  (CONTROL  F  TO  ADD,  <MENU  KEY>  TO  RETURN: 


Field  Attributes: 

Mandatory  -  id,  type,  dcreate,  dretire, 
system,  utility 

Repeat  values  for  -  type,  dcreate,  dretire, 
system,  utility,  label,  descr 
Validation-  Not  id  in  sets 

Type  in  [db,  wb,  mb,  gb] 

System  (Appendix  C)  *  selects  all 


TABLE:  sets 


id : 
type: 


1.3.4 

MENU:  Files 

FRAME:  aafiles 

USAGE:  user 

FORM:  aafiles 


PROCEDURE:  aafiles. osl 

new  =  Ccallframe  afiles;} 
old  =  Ccallframe  adfold;} 
return  =  [return;! 
exit  =  [exit;! 


1.3. 4.1 
MENU  ; 
FRAME; 
USAGE; 
FORM; 


New  Backups  or  Vendor 
af lies 

-append 
af lies 


ADD  FILE  PATH 
Table  is:  file 


id : 


part  disk: 


sav  src; 


IF  ONE  FILE  PATH  HAS  MORE  THAN  ONE  ID,  ADD  ID  AND  FILE 
PATH  FOR  EACH  ID.  IF  ID  CONTAINS  MORE  THAN  ONE  FILE  PATH 
ADD  ID  AND  FILE  PATH  FOR  EACH  FILE  PATH 


APPEND  #1  (CONTROL  F  TO  ADD,  <MENU  KEY>  TO  RETURN 


1.3. 4. 2  (Continued) 


■V 


##  append  to  file  (id=nu,  part_disk=pd ,  sav_src=ss 
##  replace  sets  ( 

##  perusd=pr 

##  ) 

3 


o 


1.3.5 

MENU;  Students 
FRAME:  astudents 

USAGE:  QBF-append 

FORM:  astudent 


ADD  ID  AND  STUDENT  DATA 
FOR  EACH  ID  THE  STUDENT'S  FILES  ARE  IN 
Table  is:  student 


id;  name; 

advisor:  contph: 

APPEND  #1  (CONTROL  F  TO  ADD,  <MENU  KEY>  TO  RETURN) : 


Field  Attributes: 

Mandatory  -  id,  name,  advisor,  contph 
id  in  sets 

Repeat  values  for  name,  advisor,  contph 


TABLE;-  student 


SELECT  UPDATE 


errors 


backup 


loan 


return 


exit 


ERRORS  BACKUPS  LOAN  RETURN  EXIT; 


PROCEDURE;  update. OS  1 


errors  =  Ccallframe  errors;) 
backups  =  Ccallframe  ubackup;) 
loan  =  Ccallframe  uloan; 3 
return  =  Creturn;) 
exit  =  Cexit;) 


mmm 


MENU: 

Backup 

FRAME: 

ubackup 

USAGE: 

QBF-update 

FORM: 

ubackup 

id : 

owner : 


UPDATE  BACKUP  OR  VENDOR  DATA 
Table  is:  sets 


dcreate: 

advisor: 


dretire 

contph: 


descr:  sequ: 

ENTER  QUERY  (<MENU  KEY>  TO  RETURN  OR  TO  RUN) :. 


Field  Attributes:  Mandatory  -  id 


TABLE:  sets 
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1.4.3 
MENU; 
FRAME ; 
USAGE ; 
FORM: 


L 

uloan 

QBF-update 

uloan 


UPDATE 

Table 

LOAN  DATA 
is:  loan 

id : 

edr ; 

loanto ; 

Icntph: 

ENTER  QUERY  (<MENU 

KEY>  TO 

RETURN  OR  TO 

RUN)  : 

Field  Attributes;  Mandatory 


TABLE:  loan 


1.5 

MENU:  Delete 

FRAME:  tdelete 

USAGE:  user 

FORM:  tdelete 


DELETE 

id : 

loan  record  (return  tapes) 

backup  (retire) 

tape  (permanently  remove) 

return 

exit 

LOAN  BACKUP  TAPE  RETURN  EXIT: 

PROCEDURE  (1):  tdelete. osl 

loan  =  Ccallproc  dloanc;) 
backup  =  Ccallproc  dbackc;) 
tape  =  Ccallproc  dtapec;3 
return  =  Creturn;} 
exit  =  Cexit ; } 
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1.5  (Continued) 


PROCEDURE  (2) ;  dloanc.qc 

dloanc  ( ) 

C 

##  int  nu; 

##  getform  tdelete  (nu=id) 

##  delete  loan  where  loan. id  =  nu 
} 


TABLE:  loan 


PROCEDURE  (3);  dbackc.qc 
dbackc ( ) 

##  int  nu; 

##  getform  tdelete  (nu=id) 

##  delete  file  where  file. id  =  nu 

##  delete  sets  where  sets. id  =  nu 

##  delete  student  where  student. id 

)  ■ 


TABLE;  file,  sets,  student 


PROCEDURE  (4);  dtapec.qc 

dtapec ( ) 

C 

##  int  nu; 

##  getform  tdelete  (nu=id) 

##  delete  file  where  file. id  =  nu 

##  delete  loan  where  loan. id  =  nu 

##  delete  sets  where  sets. id  =  nu 

##  delete  student  where  student. id 

##  replace  tape  (length=0,  bpi=0, 

where  tape. id  =  nu 


TAPE:  file,  lean,  sets,  student,  ta 
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APPENDIX  F 


IMPLEMENTATION  OF  THE  COMPUTER  SCIENCE  DEPARTMENT 
TAPE  LIBRARY  SYSTEM 


The  tape  library  system  (TLS)  application  for  the  Com¬ 
puter  Science  (CD)  Department  was  created  using  the  4.2  BSD 
UNIX  operating  system  and  the  Ingres  VMUNIX  Version  2.1/15 
VE.04  DBMS.  It  was  created  under  the  name  talibrary  cs  using 
login  name  crawfordb.  It  was  developed  using  Ingres  Appli¬ 
cations  by  Forms  (ABF).  An  executable  image  [Jlef.  4]  has 
been  built  in  the  file  /work/crawf ord  talibrary.exe  topframe. 
It  is  defined  with  the  symbol  cslib. 


A.  LOADING 

The  current  library  may  be  loaded  into  the  tables  at  this 
time.  Chapters  III  and  IV  of  this  thesis  should  be  read 
before  loading  the  library  data.  Data  may  be  loaded  into 
each  table  from  a  file  using  the  copy  command.  The  Ingres 
Self  Instruction  Guide  [Ref.  5,  p.  8-1]  provides  a  compre¬ 
hensive  explanation  of  the  procedure.  The  following  comments 
regarding  the  initial  loading  of  data  to  file,  or  directly 
via  the  application  will  ensure  the  system  operates  as 
designed . 

1 .  General 

Ingres  reads  the  value  of  an  upper  case  letter  ,lif- 
f^rentlv  than  the  value  of  a  lower  case  letter.  Manv  or  "  r.  e 


reports  are  called  by  value.  It  is  recommended  that  fields 
be  reviewed  prior  to  loading,  and  where  applicable,  values  be 
standardized  where  validation  criteria  is  not  written  into 


the  application.  Computer  records  may  not  be  duplicated  in 
the  library. 

2 .  Tables 

a.  TAPE.  All  tapes  in  the  library  must  have  at 
least  an  id  number  and  either  length  or  bpi .  If  both  length 
and  bpi  are  null,  the  application  will  report  the  id  number 
as  one  of  a  scratch  tape. 

b.  SETS .  The  table  SETS  fields  -  owner,  software, 
and  vendor  -  are  the  most  vulnerable  to  inconsistent  value 
entry.  When  a  record  is  loaded  into  table  SETS,  a  record  of 
the  same  id  must  also  be  entered  in  table  TAPE.  The  same  id 
should  never  appear  twice  within  SETS. 

c.  FILE.  More  than  one  record  in  table  FILE  may 
have  the  same  id.  If  an  id  is  included  in  TAPE,  however,  it 
must  also  be  in  SETS. 

d.  STUDENT .  Student  records  are  kept  only  for 
students  whose  files  are  contained  in  graduation  backup  tapes 
created  for  a  graduating  class.  All  of  the  graduated  stu¬ 
dents  files  should  be  recorded  on  the  graduation  backup  tape. 
The  id  numbers  refer  to  the  graduation  backup  tapes  on  which 
their  files  are  recorded.  An  id  may  appear  more  than  once  in 
the  table  STUDENT.  All  ids  in  the  STUDENT  table  shoull  be 
•.nciuded  in  tables  FILE,  SETS,  and  TAPE. 
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e.  LOAN.  An  id  should  not  appear  more  than  once  in 
table  LOAN.  All  id(s)  in  LOAN  should  appear  at  least  in 
table  TAPE,  and  may  appear  in  table  SETS  and  FILE. 

B.  TABLE  STORAGE  STRUCTURE 

The  storage  structure  of  all  tables  is  defined  as  a 
"heap”.  When  the  current  library  is  loaded,  the  storage 
structure  should  be  converted  to  "hash"  to  accelerate 
performance  of  queries.  This  may  be  done  by  the  following 
procedure.  ( %UNIX , *Ingres) 

%ingres  talibrary 

*modify  <tablenarae>  to  hash 

The  Ingres  User's  Guide  [Ref.  5]  and  the  Ingres  Reference 
Manual  [Ref.  4]  provide  further  information  on  the  structure 
and  procedure. 

C.  ACCESS 

Only  the  librarians  should  have  access  to  the  library. 
To  provide  access,  the  library  symbol  "cslib"  (no  quotes) 
must  be  defined  in  the  login  files  of  each  of  the  librarians. 
When  the  librarian  retrieves  a  printed  report  from  the  li¬ 
brary,  it  is  written  to  their  UNIX  worl<;  spaces.  Therefore 
the  librarians  need  work  spaces  large  enough  to  store  all 
reports  defined  in  the  application.  Reports  are  described  in 
Chapter  IV,  Section  G.  Documentation  regarding  the  provision 
of  access  to  users  is  in  Applications  by  Forms  ['.-ef.  c  .• 


APPENDIX  G 


TUTORIAL: 

OPERATION  OF  THE  COMPUTER  SCIENCE  DEPARTMENT 
TAPE  LIBRARY  SYSTEM  (TLS) 


TABLE  OF  CONTENTS 


A. 


B. 


FORMS - 

1.  Menu  Forms - 

2.  Parameter  Entry  (for  reports)  Forms 

3 .  Run  Report  Forms - 

4.  Append  Forms - 

a.  Programmed  id  Assignment - 

b.  Programmed  Append - 

c.  QBF-Append - - - 

5.  Update  Forms - 

6.  Delete  Form - 

THE  TLS  APPLICATION - 

1.  TQuery/Report - 

2.  PQuery/ Report - 

3.  Add - 

4.  Update - 

5.  Delete - 


C.  MAINTENANCE  PROCEDURES 

1 .  Peak  Performance — 

2.  Int:eqri^y - 

3.  Security - 


177 


This  Appendix  describes  the  operation  of  the  TLS.  Before 
using  the  TLS,  librarians  must  read  Chapter  III,  Section  B, 
Specification  Data  Dictionary;  Chapter  IV,  Section  B,  Tables 
and  Views;  and  Section  C,  Design  Data  Dictionary,  of  the 
thesis  in  order  to  understand  the  tables,  data  fields,  and 
codes  used  in  the  application.  Thorough  descriptions  and 
illustrations  of  the  frames,  forms,  procedures,  and  reports 
are  provided  in  Chapter  IV,  Section  E,  Frames;  and  Section  G, 
Frames  Definition.  These  should  be  referred  to  by  frame 
number.  Numbers  are  provided  below. 

This  tutorial  is  in  three  parts.  The  first  part  de¬ 
scribes  the  types  of  forms  used  in  the  library  and  their  use. 
The  second  part  describes  the  application  and  which  tasks  or 
functions  the  various  frames  perform.  The  third  part  de¬ 
scribes  procedures  for  the  database  administrator  to  maintain 
the  library. 

The  TLS  is  a  frame-based  application.  Each  frame  has  a 
form  and/or  report  and  a  procedure  associated  with  it.  The 
librarian  communicates  with  the  application  by  the  use  of 
forms.  The  application  responds  to  the  user  by  the  use  of 
forms  and  reports. 

The  user  may  perform  the  functions  of  add,  update,  delete 
and  retrieve.  Data  input  is  standardized  and  controlled 
through  validation  criteria.  Operations  are  selected  through 
the  use  of  menus.  The  st'.ructure  of  the  library  and  frr"’s 
march  t;ie  functions  th'-^  Librarian  cerforms. 


A.  FORMS 

There  are  six  types  of  forms  associated  with  frames  in 
the  library: 

(1)  Menu, 

(2)  Parameter  Entry  for  Reports, 

(3)  Run  Report  Forms, 

(4)  Append, 

(5)  QBF-update,  and 

(6)  Delete. 

Each  form  has  an  operations  menu  at  the  bottom  starting 
at  the  left  hand  corner.  Many  of  the  operation  menus  include 
the  operations  RETURN  and/or  EXIT.  By  selecting  RETURN,  the 
form  of  the  previous  frame  will  be  displayed'.  EXIT  will 
terminate  the  application  and  return  to  UNIX.  To  execute  an 
operation,  the  user  must  enter  a  unique  letter,  or  set  of 
letters,  which  represent  the  operation  to  the  right  of  the 
menu.  For  example,  if  the  command  menu  is: 

SCRATCH  STUD  RETURN  EXIT: 


'VV'V 

Depress 

h'V-; 

cuted  on 

"select" 

sentative 

When 

enter  sc  to  select  SCRATCH  or  enter  r  to  select  RETURN. 
Depress  <ESC>  to  execute  the  operation.  Operations  are  exe¬ 
cuted  on  all  forms  by  using  this  procedure.  The  term 
"select"  hereafter  will  be  defined  to  mean  "type"  the  repre¬ 
sentative  command  symbol,  then  depress  <ESC> . 

When  using  forms  which  include  fields  for  data  input,  the 
cursor  must  be  moved  from  field  to  field.  It  will  move  to 
the  next  field  automatically  if  the  number  of  characters  or 
ir.teg<=rs  of  tp.e  value  entered  fills  the  field.  If  it  dees 
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not,  however,  the  cursor  can  be  moved  to  the  next  field  by 
depressing  the  TAB  key.  To  move  it  back  to  the  previous 
field,  depress  control  P. 

1 .  Menu  Forms 

Menu  forms  provide  movement  to  other  frames.  They 
contain  the  list  of  other  frames  on  the  upper  portion  and  a 
matching  list  on  the  command  menu  line.  A  menu  form  is  shown 
in  Figure  11. 


SELECT  FUNCTION 

t  query/report  (terminal) 
p  query/report  (printer 
add 

update 

delete 

exit 


T  P  ADL  UPDATE  DELETE  EXIT: 


When  the  menu  form  is  displayed,  the  cursor  will 
always  appear  to  the  right  of  the  operations  menu.  To  move 
to  another  frame,  select  the  frame  desired.  The  new  form 
will  be  displayed. 

Frames  1,  1.1,  1.1.6,  1.2,  1.2.6,  1.2.8,  1.3,  1.3.3, 
1.3.4,  and  1.4  display  menu  forms. 

2 .  Parameter  Entry  (for  reports)  Forms 

Parameter  Entry  Forms  call  reports  based  on  values 
or  ranges  entered  by  the  user.  The  forms  contain  fields  in 
the  upper  portion  and  a  command  menu  at  the  bottom.  A  para¬ 
meter  entry  form  is  shown  in  Figure  12. 


ENTER  PARAMETERS  FOR  PERIODIC  BACKUP  REPORT 
Table  is:  vpe 


type : 

min_dcreate : 
part_disk : 

HELP  REPORT  RETURN: 


system : 
max_dcreate : 
sav  src: 


Figure  12.  Parameter  Entry  Form 


"Range"  fields  always  include  the  prefix  min_  or 
max  .  Those  that  do  not  are  "value"  fields.  Input  to  value 


fields  is  mandatory.  If  a  report  is  desired  of  all  values  of 
the  value  field,  an  may  be  entered.  Only  the  max_  range 
field  is  mandatory.  If  all  range  values  are  desired,  do  not 
enter  a  value  in  the  min_  range  field  and  enter  the  largest 
value  allowed  in  the  max_  range  field.  Parameter  Entry  Forms 
always  include  the  operations  HELP,  REPORT,  and  END.  HELP 
will  provide  assistance  to  the  user,  REPORT  will  run  the 
report,  and  END  returns  to  the  previous  frame.  When  a  Par¬ 
ameter  Entry  Form  is  first  displayed,  the  cursor  is  always  on 
the  first  field. 

HELP  may  be  selected  at  any  time  during  parameter 
entry.  The  form  will  be  redisplayed  intact  after  HELP  has 
been  obtained.  Select  REPORT  to  run  the  report  after  ranges 
and  values  have  been  entered.  Select  END  to  return  to  the 
previous  frame  without  running  the  report. 

Frames  1.1.1,  1.1.2,  1.1.3,  1.1.4,  1.1.5,  1.1. 6. 2, 
1.1.7,  1.2.1,  1.2.2,  1.2.3,  1.2.4,  1.2.5,  1.2. 6. 2,  and  1.2.'', 
display  Parameter  Entry  Forms. 

3 .  Run  Report  Forms 

Run  Report  Forms  are  used  to  run  reports.  I’c 
selection  of  values  is  available  to  the  user.  A  xPun  Report 
Form  is  shov'/n  in  Figure  13. 


outputs  to  file;  plnscratch 

HELP  REPORT  RETURN: 


Figure  13.  Run  Report  Form 

The  upper  portion  is  either  blank  or  displays  a  line  inform¬ 
ing  the  user  to  which  file  the  report  will  be  written.  The 
command  menu  line  is  the  same  as  report  parameter  entry 
forms . 

Frames  1.1. 6.1,  1.2. 6.1,  1.2. 8.1,  1.2. 8. 2,  1.2. 8. 3, 
1.2. 8. 4,  and  1.2. 8. 5  display  Run  Report  Forms. 

4 .  Append  Forms 

Append  forms  allow  the  user  to  append  new  records  to 
the  library.  They  display  fields  on  the  upper  portion  for 
data  entry  and  a  command  menu  line  at  the  bottom.  Append  is 
simple;  there  are  three  variations  of  Append  Forms. 

a.  The  first  type  of  Append  Form  provides  programmed 
id  assignmient,  and  is  shown  in  Figure  14. 

This  type  of  form  is  associated  with  a  procedure 
which  automatical ly  assigns  an  id  number  and  perhaps  another 
value  ro  the  form.  The  fields  wi'.ich  are  au  t  cira  ‘  :  ca  1  1  y  as- 


'1  r  1:  '  r  c  i  s  r  i  a  v  o  n  ^ . 


'ursor  w: 


ADD  SCRATCH  TAPES 
Table  is:  tape 


Figure  14.  Append  Form  (Programmed  id  Assignment) 

on  the  first  field  in  which  data  may  be  entered  when  the  form 
is  initially  displayed.  Before  entering  new  data,  the  id 
number  must  be  assigned.  The  command  line  at  the  bottom  dis¬ 
plays  operations  ID,  ADD,  and  RETURN. 

To  get  an  id  assigned,  first  move  the  cursor  to 
the  command  line  by  depressing  <ESC>,  then  enter  i  RETURN. 
An  id  and  perhaps  other  data  will  be  assigned.  Relevant 
notes  regarding  the  labelling  of  cabinet  spaces  and/or  tapes 
v/ill  be  displayed  next  to  the  command  line  for  tv.c  secon.ds  . 
If  the  display  says  OLD  ID,  it  means  the  cabinet  space  has 
been  previously  labelled,  and  the  space  is  erapty.  Therefore, 
only  the  tape  need  be  labelled.  If  the  display  states  '■  EW 
ID,  no  spaces  were  empty  and  a  new  id  has  been  added  to  tiie 
library.  Both  the  space  ana  the  tape  must  be  labelled. 

hf'er  ti;e  id  is  obtained,  the  cursor  vO  1  !  ap'-.c 
sr.  nirst  iisbi  i:;  v/l:ch  da^a  nv;"  bo  ^  '  n;.: 


data,  move  the  cursor  to  the  command  menu  line  and  select 
ADD.  After  the  append  has  been  completed  the  form  will  be 
redisplayed.  All  fields  will  contain  the  old  values  except 
id.  A  new  record  may  be  entered  which  has  all  the  same 
values,  except  id,  by  simply  selecting  ID,  then  ADD,  or  a  new 
record  may  be  entered  by  selecting  ID  and  typing  over  the 
displayed  values,  then  select  ADD.  When  all  new  records 
have  been  added,  select  RETURN  to  display  the  previous  frame. 

Frames  which  display  programmed  id  assignment 
forms  are  1.3.1  and  1.3.2. 

b.  Another  type  of  append  fram.e  is  the  program.m.ed 
append,  shown  in  Figure  15. 


ADD 

FILE  PATH  TO  OLD  PARTIAL 
Tables  are;  file  and 

INDIVIDUAL 

sets 

id : 

part  disk: 

sav  src: 

perusd ; 

1 

enter  data  and  select 

1 

add 

ADD 

RETURN 

EXIT: 

Figure  15.  Append  Form  ( Program, med  Append) 


m 


m 


In  the  upper  portion,  the  form  displays  fields 


into  which  data  may  be  entered.  It  displays  the  command 


menu  ADD,  RETURN,  and  EXIT  at  the  bottom.  When  the  form  is 


initially  displayed,  the  cursor  will  always  appear  on  id.  To 


add  new  records,  simply  enter  new  data  and  select  ADD. 


Frame  1.3. 4. 2  displays  a  programmed  append  form. 


c.  The  third  type  of  append  form  is  a  QBF-append. 


The  initial  display  of  a  QBF-append  form  is  shown  below  in 


Figure  16 


ADD  ID  AND  LOAN  DATA  FOR  EACH  ID  LOANED 
Table  is:  loan 


dloan ; 


loanto : 


Icntph ; 


APPEND  #1  (CONTROL  F  TO  ADD,  <MENU  KEY>  TO  RETURN) 


Figure  16.  QBF-append  Form 


To  add  data,  fill  in  all  the  data  fields  dis¬ 


played  in  the  upper  portion  and  depress  control  F ;  the  cursor 


Joes  not  need  to  be  on  the  command  menu  line.  After  tne  ne'i 


record  has  been  entered  the  following  form  (Figure 


Le  displayed 


ADD  ID  AND  LOAN  DATA  FOR  EACH  ID  LOANED 
Table  is:  loan 


dloan: 


loanto ; 


Icntph : 


APPEND  #2  (CONTROL  F  TO  ADD,  <MENU  KEY>  TO  RETURN) 


Figure  17.  QBF-append  Form 


In  some  forms,  some  of  the  fields  will  retain  the 
previous  values.  If  the  previous  value  is  not  displayed,  it 
may  be  recalled  by  putting  the  cursor  in  the  field  and 
depressing  control  a.  This  will  be  especially  helpful  if  you 
cannot  remember  the  number  of  the  last  id  entered.  To  add 
another  record,  simply  change  the  appropriate  values  and 
enter  control  f.  If  you  do  not  desire  to  add  more  records, 
depress  the  menu  key  <ESC>  and  the  form  shown  in  Figure  18 
will  be  displayed. 

KELP  provides  information  regarding  QEr.  ADD 
allows  you  to  continue  adding  data.  If  END  is  selected,  the 
previous  form  will  be  displayed.  Frames  which  display  CEF- 
append  forms  are  1.3. 3.1,  I. 3. 3. 2,  1.3. 4.1,  1.3.5,  and  1.3.6. 
More  detailed  information  regarding  CBF'^ppend  frames  is  pro¬ 
vided  in  the  Ingres  CEE  Users  Guide  [Ref.  6]. 


ADD  ID  AND 

LOAN  DATA  FOR  EACH  ID  LOANED 

Table  is:  loan 

id : 

dloan:  edr: 

loanto : 

Icntph : 

HELP 

ADD  END: 

Figure  18.  CBF-append  Form 

5 .  Update  Forms 

Update  forms  are  used  to  change  values  of  records 
previously  entered  in  the  library.  The  update  function  con¬ 
sists  of  two  states,  the  QUERY  state  and  the  GO  state.  While 
in  the  QUERY  state,  you  may  specify  a  query  by  filling  in  the 
form  with  the  values  of  the  records  you  are  searching  for. 
After  filling  in  this  form,  QBF  enters  the  GO  state,  re¬ 
trieves  the  row(s)  you  asked  for,  and  allows  you  to  upd3*;e 
each  row,  one  by  one.  The  changes  are  stored  in  a  tenpciarj 
buffer,  as  you  move  from  row  to  row.  After  changing  all  ‘■fe 
rows,  you  can  v/rite  out  the  buffer  containing  the  ci-ianges  ♦:c 
tile  table.  After  you  update  the  table,  you  are  returned  tc 

ti'ie  QUERY  state  to  execute  a  new  query.  You  ('an  leave  the 

QUEFY  cr  GO  states  a^  any  time,  either  tc  ex<='cutt  arc";'':r 

r"  :  r  *"0  r-^‘ti;rn  to  r.-.-r  main  mer'i  l  *  ;r^-2:at:.;'o  s'-c''  n. 


y  ':-.t  -/-■■vgav  ::  ■.  v -y-Q'-y -y,  > 


QBF-update  frames  display  the  form  shown  in  Figure  19 


when  selected. 


UPDATE 

LOAN 

DATA 

Table 

is : 

loan 

id : 

edr : 

loanto : 

Icntph : 

ENTER  QUERY  (<MENU 

KEY>  TO 

RETURN  OR  TO  RUN) : 

Figure  19.  Update  Form  (Query  State) 

This  is  the  QUERY  state.  Fill  in  the  value  or  values 
of  the  records  you  wish  to  retrieve.  For  the  TLS ,  you  will 
usually  call  records  for  update  by  id.  You  may  use  compari¬ 
son  operators  when  specifying  a  query.  These  are: 

>  greater  tiian  >=  greater  than  or  equal  to 

<  less  than  <=  less  than  or  equal  to 

=  equal  to  !=  not  equal  to 

'.vi'ile  in  the  QUERY  state,  QBF  does  not  check  fields  to  make 

sure  they  contain  valid  data.  This  is  done  when  \-ou  enter 
the  GO  state  to  run  the  query. 

The  QUERY  state  has  a  menu  for  runninq  cueries,  r-.^- 


help.  To  call  the  menu,  depress  the  <ESC>  key.  The  menu 
appears  at  the  bottom  of  the  screen. 


HELP  QUERY  GO  END  <command> 


You  may  call  the  menu  at  any  time;  it  does  not  affect 
your  data.  If  the  menu  was  accidently  called,  depress  RETURN 
to  return  to  your  form.  To  exit  UPDATE,  select  the  END  ccm- 
mand  and  you  will  be  returned  to  the  previous  frame.  If  you 
select  QUERY,  QBE  clears  all  the  fields  on  your  form  sc  that 
you  can  enter  a  new  query.  All  data  on  the  old  form  is  lost. 
If  you  select  GO  the  query  is  run.  QBE  enters  the  GO  state. 
QBE  will  now  display  the  following  form  (Eigure  20)  with  the 
values  of  the  record (s)  you  requested.  You  can  now  edit  the 
rows  you  have  just  asked  for  by  typing  the  new  data  over  the 


UPDATE  LOAN  DATA 
Table  is:  loan 


Icanto:  crawfori 


edr  :  9 


1  c  n  t  r  h 


i  TYPE  IN  NEW  DATA  (<E5C>  TO  RETURN,  CONTROL-F  FOR  NE 


F  o  r  m  ( 


'll 


If  no  rows  which  satisfy  the  query  are  found,  QBF 
displays  the  message  -  NO  ROWS  FOUND  -  and  returns  to  the 
QUERY  state  so  you  may  enter  a  new  query. 

If  you  wish  to  go  to  the  next  row  specified  by  ycur 
query,  depress  the  control  F  key.  If  no  rows  are  left,  NO 
MORE  ROWS  LEFT  IN  QUERY,  is  displayed. 

At  this  point  you  have  three  options;  (1)  write  ycur 
changes  to  the  table;  (2)  start  a  new  query;  or  (3)  exit 
UPDATE,  using  the  GO  state  menu. 

Your  changes  are  stored  in  a  buffer  each  time  ycu 
depress  the  control  f  key.  These  changes  do  not  change  the 
table  in  the  library  until  you  issue  the  WRITE  command  in  the 
GO  state  menu. 

To  enter  the  GO  state,  depress  the  <E£C>  key.  The 
following  menu  will  be  disolayed:  HELP  QUERY  WPITE  DELETE 
END.  You  may  call  this  menu  at  any  time.  It  does  not  affect 
your  data.  To  exit  without  writing  your  changes,  select  END. 
Ycu  will  be  returned  to  the  previous  frame.  If  ycu  want  to 
be-'ir.  ycur  query  again,  select  QUERY.  The  changes  made  w:  ]  1 
Le  erased  from  tiie  buffer  and  the  QUERY  formi  will  be  display- 
-i'-.i  .  Tr.e  DELETE  key  deletes  tne  current  row  cispldvec’.  cr.  “'..a 
scr'-aan.  Fhere  is  no  reason  tc  use  rb,is  key  in  rh.e  ]ibr=.ry. 

To  write  th.e  changes  you  nave  ri;ac;e  tc  the  row  is.)  , 
Sv^-lect  ‘:ne 


V<F1TE  operation. 


If  VC  u  h  a  V  e  m  o  e  c  hi  a  n  o  c- : 


IS  displayed:  DO  YOU  WANT  TO  LEAVE  UPDATE  WITHOUT  WRITING 
CHANGES?  Enter  y  for  yes  and  n  for  no. 

Further  information  about  UPDATE  is  provided  in  the 
Ingres  QBF  User's  Guide  [Ref.  6].  QBF  UPDATE  frames  are 
1.4.1,  1.4.2,  and  1.4.3. 

6.  Delete  Form 


The  Delete  Form  (Figure  21) ,  is  used  to  delete 


records . 


DELETE 


loan  record  (return  tapes) 

backup  (retire) 

tape  (permanently  remove) 


return 


exit 


LOAN  BACKUP  TAPE  RETURN  EXIT 


Figure  21.  Delete  Form 


Cn  the  upper  portion,  a  field  for  id  and  a  list  of  operations 
"o  be  performed  cn  ti.e  id  number  is  displayed. 


I  »  m  mT.  • 


The  command  menu  repeats  the  operations  listed  on  the 
upper  portion.  Additionally/  RETURN  calls  the  previous 
frame;  EXIT  exits  the  application. 

To  use  the  delete  frame,  enter  the  id  number  of  the 
tape  on  which  the  delete  operation  is  to  be  performed.  Move 
the  cursor  to  the  command  menu  and  select  the  delete  oper¬ 
ation  desired.  The  delete  occurs  immediately. 

Frame  1.5  displays  a  delete  form. 

B.  THE  TLS  APPLICATION 

Each  of  the  librarians  has  been  granted  atcess  to  the 
library.  It  may  be  called  from  UNIX  by  entering  (%  is  the 
UNIX  prompt) :  %  cslib 

The  first  TLS  frame  will  display  a  form  on  the  screen. 
The  name  of  the  frame  is  Topframe  and  is  number  1  in  Appendix 
D.  Topframe  is  the  main  menu  of  the  application.  It  displays 
the  major  operations  performed  in  the  library: 

(1)  TQuery/Report  -  print  a  report  to  the  terminal 

(2)  PQuery/Report  -  print  a  report  to  the  librarian's  UNIX 

workspace . 

(3)  Add  -  add  new  records 

(4)  Update  -  correct  incorrect  values 

(5)  Delete  -  delete  records 


If  TQuery/Report  is  selected,  a  choice  of  the  follow¬ 


ing  reports  is  displayed  on  the  terminal: 

o  Scratch  (1.1.1)  -  for  scratch  tapes  available. 

o  Periodic  (1.1.2)  -  for  aperiodic  backups  stored  in  the 
library  (daily  backup  (db) ,  weekly  backup  (wb) ,  monthly 
backup  (mb) ,  or  graduation  backup  (gb) . 

o  Individual  (1.1.3)  -  backups  belonging  to  individual 

staff  (is)  ,  faculty  (if)  ,  or  students  (iu)  (before  they 
graduate) . 

o  Vendor  (1.1.4)  -  vendor  (v)  tapes,  no  matter  to  whom 
they  belong. 

o  Student  (1.1.5)  -  graduated  students  and  the  tapes  on 
which  their  accounts  are  logged. 

o  Loaned  (1.1.6)  -  a  choice  of  Loaned  Scratch  Tapes 

(1.1. 6.1)  or  Loaned  Backup  or  Vendor  Tapes  (1.1. 6. 2) 
(Date  to  Retire  (1.1.7)  tapes  by  retirement  date). 

2.  PQuery/ Report  (1.1.2) 

If  PQuery/Report  is  selected,  a  choice  of  the  same 

reports  as  in  TQuery/Report,  and  one  additional  report  is 

displayed.  The  additional  report  frame  available  is  DUMP. 

o  Dump  (1.2.8)  -  Dump  provides  a  choice  of  five  reports. 
They  are  each  a  "dump"  of  one  of  the  five  tables:  Tape 

(1.2. 8.1) ,  Sets  (1.2. 8. 2),  File  (1.2. 8. 3),  Student 
(1.2. 8. 4),  and  Loan  (1.2. 8. 5).  They  contain  all  of  the 
fields  in  the  tables  and  are  sorted  by  id  number. 

The  reports  selected  by  the  PQuery/Report  frame  will 

be  written  to  your  UNIX  workspace  file.  The  name  of  the  file 

is  displayed  on  the  terminal.  The  file  may  then  be  printed 

by  using  UNIX. 


Add  should  be  selected  whenever  you  desire  to  add  any 
new  records  to  the  library.  Add  provides  a  choice  of  adding 
the  following: 

o  Scratch  (1.3.1)  -  to  add  new  scratch  tapes 

o  Vendor  (1.3.2)  -  to  add  vendor  tapes 

o  Backup  (1.3.3)  -  to  be  used  when  a  backup  has  been  read 

to  a  scratch  tape.  Backup  provides  a  choice  to  add: 

Periodic  backups  (1.3. 3.1)  (type  db,  wb,  mb,  gb)  or 

Individual  backups  (1.3. 3. 2)  (type  is,  if,  iu) 

o  Files  (1.3.4)  -  is  to  be  used  to  record  the  file  paths 
which  have  been  read  to  each  tape.  A  choice  of  situ¬ 
ations  is  provided: 

New  Backup  or  Vendor  (1.3. 4.1)  -  This  frame  will  be 
used  to  add  file  paths  at  all  times  except  the 
following 

-  Old  Partial  Individual  (1.3. 4. 2)  -  This  frame  will 
be  used  only  when  an  individual  has  requested  a 
file  path  be  read  to  tape  and  the  librarian  selects 
one  of  the  individual's  old  partially  used  tapes  to 
perform  the  read.  The  new  file  path  should  be 
recorded  using  the  id  of  the  old  tape. 

4 .  Update  (1.4) 

Update  should  be  selected  whenever  you  desire  to 
change  values  which  have  been  previously  entered  in  the 
library.  Update  provides  three  choices  for  the  changes: 

o  Errors  (1.4.1)  -  After  a  tape  is  read  or  written,  the 
utility  may  indicate  that  the  number  of  tape  errors  is 
different  than  those  recorded  in  the  library.  Use 
Errors  to  update  the  number  of  errors  and  the  date  the 
new  errors  are  entered. 


o  Backup  (1.4.2)  -  Backup  enables  updates  to  the  follow¬ 
ing  fields  concerning  backup  or  vendor  tape  records: 

dcreate,  dretire,  owner,  advisor,  contph,  descr,  sequ. 

o  Loan  (1.4.3)  -  Loan  allows  you  to  change  fields  edr, 
loanto,  and  Icntph. 

5.  Delete  (1.5)  -  Delete  is  the  only  frame  which  should 
be  used  to  delete  records  from  the  library.  The  operations 
available  are: 

o  Loan  -  Use  when  a  loaned  tape  is  returned.  This  oper¬ 
ation  deletes  the  record  of  the  loan. 

o  Backup  -  Use  when  a  backup  tape  is  retired  or  erased, 
but  the  tape  is  retained  to  be  used  as  a  scratch.  All 
records  of  the  backup  are  deleted  from  the  library. 

The  data  regarding  the  physical  characteristics  and 
condition  of  the  tape  are  retained.  The  tape  keeps  its 
id  number,  and  must  be  left  in  its  cabinet  space. 

o  Tape  -  When  a  tape  is  permanently  disposed.  All  re¬ 
cords  of  the  tape  are  deleted  from  the  library.  Only 
the  id  number  of  the  cabinet  space  is  retained  and  the 
TLS  will  define  the  id  number  as  an  empty  slot.  The 
tape  must  be  removed  from  the  cabinet  space,  and  the  id 
number  must  be  removed  from  the  tape.  The  cabinet 
space  retains  the  id  number. 


C.  MAINTENANCE  PROCEDURES 

As  discussed  in  Chapter  IV,  Section  J,  the  database  ad¬ 
ministrator  will  be  required  to  perform  tasks  to  maintain 
peak  performance,  integrity,  and  the  security  of  the  data¬ 
base.  The  following  is  recommended. 


1.  Peak  Performance 


On  a  monthly  basis,  run  a  system  modification  on  each 
table  in  the  database.  This  may  be  done  by  entering  the 
following  at  the  UNIX  operating  system  level  (%  UNIX): 

%  sysmod  talibrary 

%  sysmod  talibrary  tape  sets  file  student  loan 

2 .  Integrity 

Only  the  librarians  should  be  granted  permits  to 
affect  the  TLS  tables.  Destroy  and  define  permits  to  tables 
as  personnel  are  relieved  of  their  librarian  duties  and  new 
personnel  are  assigned.  The  procedure  for-  granting  and 
destroying  permits  is  provided  in  Appendix  F,  Section  D. 

3 .  Security 

Only  librarians  should  have  access  to  the  library. 
Access  is  made  available  by  defining  the  TLS  login  symbol  in 
the  login  files  of  new  librarians.  The  login  sign  should  be 
deleted  from  the  login  files  of  personnel  relieved  of  librar¬ 
ian  duties.  The  procedure  for  providing  and  denying  access 
is  discussed  in  Appendix  F,  Section  C. 
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